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
8a57bd2461
SQLOperator gets the axe.
2009-09-10 03:44:00 +00:00
02cccbc0ea
I'm not going all the way down this path today, but now that we've hidden the
...
implementation of operators and expressions, we can go the whole nine yards and
eliminate the named classes entirely (except in cases where we need them for
multiple dispatch by the visitors). Demonstrated this neatness with And and Or.
2009-09-10 03:41:30 +00:00
ff250b2edd
Extracted BinaryOperator and MultiOperator into top-level classes in
...
preparation for possibly nixing SQLOperator, which appears to me to be unused
if not unnecessary.
2009-09-10 03:35:03 +00:00
03008f6168
This package no longer needed. Want operator to go away too...
2009-09-10 03:24:29 +00:00
4d322fb732
Jihad complete, operators hidden behind the impl veil.
2009-09-10 03:22:34 +00:00
3c5b35612c
We're having an existential crisis. There are two exists() methods.
2009-09-10 03:15:37 +00:00
ee1ced3f30
Added Ops.exists().
2009-09-10 03:05:34 +00:00
7a350474f5
Added exists() as well as a static add() and mul() for times when it seems
...
weird to use those fluently. Might also add div() and sub() but I'm currently
wondering why those have varags constructors Div(SQLExpression... values). What
does foo / bar / baz mean exactly? That's a rhetorical question, division is
left associative, but it's still weird and too non-obvious IMO. foo - bar - baz
is also wonky.
2009-09-10 02:56:21 +00:00
a6c113e490
Added Ops.like().
2009-09-10 02:38:58 +00:00
89a15571ed
Another spot where we need to return non-specific types.
2009-09-10 02:23:24 +00:00
a5face282b
Well, OK. We're going to take the pain and break binary compatibility and use
...
thsi opportunity to move a whole heap of stuff into impl that doesn't really
need to be visible to external parties. We're changing the return value of all
expression creating factory classes to SQLExpression or FluentExp because those
expose all the functionality one might need on the returned values and there's
otherwise no value to be had getting an And() or a LiteralExp() and a downside
of preventing us from replacing the implementation of those expressions without
breaking binary compatibility.
I hemmed a bit about everything in depot.operator. In theory everything there
is available via a combination of Exps and FluentExp but in practice Whirled
uses a ton of those classes directly (whre a ton is defined as 64 imports of
classes in depot.operator). Perhaps I'll go on a cleanup jihad there and then
move all that to impl as well.
The rabbit holes, they always go deep.
2009-09-10 02:18:38 +00:00
cf49fbbc9a
Let's switch these to less specific return types before they end up out in the
...
wild.
2009-09-10 00:59:15 +00:00
0326468e8e
These need to return FunctionExp to be binary compatible. Let this be a
...
reminder why it can be useful not to return the most specific type possible
from a method, but rather a more general supertype that allows us to change the
internals of the method without losing binary compatibility.
2009-09-10 00:52:23 +00:00
Ray Greenwell