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
fce9e56aca
Provide these as deprecated for a short while to preserve binary compatibility
...
for Samsara apps.
2009-09-10 00:34:08 +00:00
47e6f6f552
Now that we have explicit Ln() and Log10(), let's get rid of the hopelessly esoteric arbitrary-base Log().
2009-09-09 20:57:08 +00:00
14c1bdd860
Call the convenience collection Funcs, not Funs.
2009-09-09 20:02:51 +00:00
92fd3054ca
Handle the new Log10 class.
2009-09-09 19:57:58 +00:00
2ae7d6146b
Unintentional commit.
2009-09-09 19:56:11 +00:00
12fabe42f7
Actually, that can't happen, so let's handle it more gracelessly.
2009-09-09 19:55:43 +00:00
27dcb0e753
Eclipse-warning tweaks from Charlie.
2009-09-09 19:52:56 +00:00
9c68929213
It turns out PostgreSQL supports LN(exp) and LOG(exp) in double precision, but not LOG(base, exp). So we're adding an explicit LOG10. I wonder how useful the two-argument one is... maybe we should delete it.
2009-09-09 19:51:33 +00:00
32bccc3dd7
Deprecate FunctionExp in favour of explicit support for many common SQL functions, whose convenience factory methods reside in com.samskivert.depot.Funs. The EpochSeconds class is also deprecated in favour of Funs.dateEpoch().
2009-09-09 14:39:55 +00:00
f871b08383
Tiny typo.
2009-09-04 21:36:34 +00:00
3032a1e568
Connection.isClosed() is new in 1.6 and Connection.close() is a no-op if the connection is already closed, so let's go for brevity here and save people from having to have 1.6-specific JDBC drivers.
2009-09-04 19:06:25 +00:00
82d742ec09
A (slightly modified) patch from Charlie to use the magical statement
...
collecting Connection to automatically close all statements created during the
course of our operations.
2009-09-04 17:37:57 +00:00
52a9c2036f
Charlie's commit patch; if we're not in the auto-commit state, let Depot explicitly commit its operations. If we add transaction awareness to Depot in some future, this behaviour might become more subtle.
2009-09-03 22:12:44 +00:00
Par Winzell