93d90083a1
Use single quotes around the truncation parameter.
...
(Assume future enums in DateTruncate will correspond to the postgres args).
2010-03-02 21:36:29 +00:00
cb86b6def4
If we're shadowing a field, let's try using the shadowed column's name.
2010-03-02 21:30:20 +00:00
42d99f90ca
Some language about the proper usage of Sequence.
2010-02-25 23:17:06 +00:00
0b51d1e62f
Formatting.
2010-02-25 22:35:15 +00:00
4b1ffe3df9
We need to specify that we want to call the varargs version, not the Iterables version. Screw Java.
2010-02-25 18:48:54 +00:00
6930ed5b40
Bring back this test: WithKeys's constructor begins with iterator().next().getClass() and it's not obvious to me that it can made to elegantly not knowing that class.
2010-02-25 18:48:24 +00:00
0b8be77564
Unused import.
2010-02-25 18:47:17 +00:00
aa4ac73e5d
Fixed some javadoc bugs.
2010-02-25 06:52:07 +00:00
b5e7ba8642
Whitespace patrol.
2010-02-25 06:49:07 +00:00
b8d957ce4c
Accept Iterable rather than Collection everywhere we reasonably can.
...
Note one potentially consequential diff in DepotRepository:
- return keys.isEmpty() ? Collections.<T>emptyList() :
- _ctx.invoke(new FindAllQuery.WithKeys<T>(_ctx, keys));
+ return _ctx.invoke(new FindAllQuery.WithKeys<T>(_ctx, keys));
This should not actually impact anything. FindAllQuery.WithKeys first checks
for keys that are cached, coping with a potentially empty set (there will be
none), then if there are keys that remain to be loaded from the database, it
loads them. The first check will NOOP as will the second check. So this should
just be a slightly more circuitous path to getting back an empty collection. It
should not result in a zero row matching query being sent to the database.
With that in mind, it seemed inelegant to prematurely optmize the return of an
empty collection.
2010-02-25 06:48:27 +00:00
950653960b
Separate SeqImpl out of Sequence, hiding it away in our impl package tree. Make
...
Sequence an interface.
We're going to change all of the places in Depot where we take a Collection as
an argument and take an Iterable instead. We invariably just turn the
Collection to an array, and we can just as well do that with an Iterable and be
more flexible about what we accept. Iterables.toArray has a fast path for
Iterable instances that also implement Collection, so we make SeqImpl implement
Collection under the hood even though we don't advertise that in the Sequence
interface because we don't want people using these as collections.
What we really want is something in between Iterable and Collection that knows
its size but otherwise does not allow mutation or containment checks.
2010-02-25 06:30:12 +00:00
503f3893cb
XList is now an ex-List.
2010-02-25 06:12:22 +00:00
e972ebc72b
Added toSet().
2010-02-24 22:01:25 +00:00
6255819745
Twice now I've blown this comment.
2010-02-24 17:34:03 +00:00
17a6cb3332
Comment pedantry.
...
Considered adding a note that toArray() is generally not safe, but the
Collections run through here in normal depot usage will be safe to use.
Check out the implementation of AbstractCollection's toArray(T[]).
2010-02-24 02:07:36 +00:00
9444cad7d8
Check our preconditions for fast failure, and added toArray().
2010-02-23 22:27:30 +00:00
e251cd9944
This guy needs also to be marked deprecated to let the compiler know that I
...
know that it's implementing a deprecated interface method.
2010-02-23 08:54:54 +00:00
54b7bf9e99
Bring on the deprecation warnings.
2010-02-23 08:47:46 +00:00
b022382231
XList is going away. To be replaced with this, still somewhat out of place in a
...
database library but at least slightly more ignorable, bit of functional
helpfulness.
2010-02-23 08:35:30 +00:00
152ff056d9
Charlie has convinced me that the database manipulation operations should be
...
public and I should not force everyone who wants to use Depot to route all
database accesses through custom public methods that hide all of the underlying
Depot business behind application specific APIs.
I still think this is the best way to use Depot, but I acknowledge that there
are certain valid use cases (like generic code that operates on records in
arbitrary repositories) which are precluded by this scheme. So instead I'll
just strongly suggest that Depot be used in the way I think it should, and
frown sternly at anyone who deviates from The Way.
2010-02-23 07:30:58 +00:00
1fe2c451f8
Both In() and IsNull() will work on general expressions, not just columns.
2010-02-22 18:58:57 +00:00
cdeb8eac8a
Fail with a useful error message any time a migration tries to reference a
...
non-existent field.
2010-02-10 16:47:31 +00:00
9661056e10
Be more flexible: follow the "PECS" rule for our Function.
2010-02-05 02:33:57 +00:00
4fca0623dd
Ray's patch to fix empty table insertion.
2010-02-03 20:36:16 +00:00
94d381b8cc
It's convenient when the toString()'d values are valid SQL.
2010-01-27 17:09:41 +00:00
d079445420
I'm not sure why I thought this was a good idea last night, even temporarily for testing, but it's certainly not anymore.
2010-01-27 17:08:12 +00:00
f0c8d185f0
With last night's patch to MultiKeySet, we'll be using a lot more IN() statements, and some of them contain shorts and bytes. Handle it.
2010-01-27 15:21:57 +00:00
c8eb3be297
An ancient TODO entry, now with a checkbox next to it. The way we load records (by loading keys first, then the records by key) has hitherto created really cumbersome expressions when the records in question have multi-column keys. We'd get basically SELECT * from FOO where (A = 1 and B = 'x') or (A = 1 and B = 'y') or ... and so forth, for another 30,000 arguments. This happens constantly, and we're not sure we want to trust PostgreSQL to always be handling such a flagrantly suboptimal structure elegantly. So, we now optimize it ourselves. When possible, turn constructions like the previous into where (A = 1 and B in ('x', 'y', ...)). This code has not been tested against serious amounts of data, so I am doing a sneaky midnight commit to easily test on Whirled Dev.
2010-01-27 07:39:43 +00:00
784d3c18ca
Typo fix, TODO note.
2009-12-10 15:48:54 +00:00
4c21819f22
Adapt to the new google-collect jar. Thanks Charlie.
2009-11-11 20:41:31 +00:00
6d745b4247
Roll back Charlie's constructor patch. It's an admirable idea but it just adds too much unwieldy boilerplate to large records, and neither of us like the idea of on/off switches. We'll just have to construct by hand.
2009-10-29 17:38:47 +00:00
116679ebfe
Get rid of @Column(type=...) which was always an abomination.
2009-10-29 16:33:34 +00:00
4e390ecb0e
Charlie's patch to generate field-instantiating constructors for records that do not have existing (non-generated) constructors. Generated, nullable or default-value'd fields are ignored by the constructor.
2009-10-26 15:30:53 +00:00
4b43b7d099
We'd accidentally conflated SQL expressions and SQL clauses into the one interface SQLExpressionsf, which would allow statements like 'FooRecord.BAR.add(FooRecord.getKey(1))' to compile erroneously. Let SQLExpressions and QueryClauses both be subclasses of a new type SQLFragment, and let our ExpressionVisitor be a FragmentVisitor.
2009-10-23 13:59:47 +00:00
8f25455481
More convenient multi-column indexing! From Charlie.
2009-10-15 16:21:14 +00:00
27b7790275
Remove some superfluous bits. From Charlie.
2009-10-15 16:20:55 +00:00
9c0c3be37b
Aii, ColumnDefinition.defaultValue is null when it's unset, unlike the annotation.
2009-09-29 20:10:07 +00:00
d3e10710d2
Whitespace tweak.
2009-09-25 00:47:33 +00:00
e2d4269516
Patch from Nathan to support longs.
2009-09-25 00:41:18 +00:00
4a552b29bc
Let's not run this MySQL atrocity unless absolutely necessary.
2009-09-22 21:33:42 +00:00
681f420b8f
Patch from Charlie to always commit if auto-commit is off.
2009-09-22 01:54:38 +00:00
04dc2daa8b
More Galileo hygiene.
2009-09-15 04:53:50 +00:00
6a4c14b1eb
Some Galileo inspired raw type elimination.
2009-09-14 22:18:09 +00:00
95e4e2d7da
Javadoc cleanup and improvements.
2009-09-13 03:05:37 +00:00
d20d518b8e
Sometimes specifying the enclosing class is informative and useful other times
...
(much less frequently) it is too verbose. Here I want to be informed.
2009-09-10 19:01:57 +00:00
b331be7ed8
While we're fooling around (and since we've been Calendar maniacs lately),
...
let's name these DateFuncs nicely.
2009-09-10 19:00:16 +00:00
b49150a0ae
Nix the examples.
2009-09-10 18:50:56 +00:00
14fffdeb3a
Split the functions into multiple files as there are a zillion of them and it's
...
useful clarification to see MathFuncs.trunc() versus DateFuncs.truncToDay(),
for example.
2009-09-10 18:50:37 +00:00
e37c18ca50
Missed some rather important bits in the last commit.
2009-09-10 16:59:33 +00:00
aa29b143af
Depot's caching strategy relies on every clause and all its subexpressions constructing deterministic toString()'s. We do it by requesting that each function implementation returns an identifying string. We could use StringUtil.shortClassName() as things stand now, but I think perhaps MDB wants to get rid of the named classes.
2009-09-10 15:26:54 +00:00
Ray Greenwell