- Added an IntegerIterable Transformer.
- Document that these *Iterable transformers work with List/Set/Collection...
In case it wasn't clear.
- Added a sizeHint argument to the createCollectionBuilder method, take
advantage of that in the IntegerIterable since we don't need to do any
work to find the size.
It blows up expecting a column name in the values parenthesis, but the default values string that
postgres was working seems to work. It's not in http://hsqldb.org/doc/guide/ch09.html, but so it
goes.
I would have prefered to only add this support to the Query interface, and not
clutter up DepotRepository with two additional overloaded methods. However,
that would not have been possible without duplicating a bunch of logic from
DepotRepository. Yet another reason why the Query builder approach is awesome
and the fuckloads of overloaded methods approach isn't.
enum, when we need it to be using name() instead. We just take care to send it
the results of name() instead of the enum value itself.
It would be nice to share this code with BuildVisitor.bindValue, but that would
require yet further twisting and factoring of the code, obscuring it even more.
We'll just hope that special cases like Enum and ByteEnum aren't going to keep
cropping up.
it in our internals. We actually do use the toString value, but only in
constructing the cache key for a query, which should generally not result in
badness, unless you override your enums to not return unique strings for
different enum values.
It's looking like the Postgres4 driver calls createArray with an Object[] full
of enums, and it calls toString on the values in the array. I have an idea for
how to fix that, which is coming up next.
depot with a 1.5 compiler is going to blow up with a mismatched version. Go back to 1.5 in build.xml
and pom.xml, but leave Eclipse using a 1.6 JVM. This means if anyone regenerates the m2eclipse
configuration, this will break in Eclipse again. Lame.
in its burning desire to support the amazing four hundred billion rows, returns
a Long for count expressions.
Clients using selectCount() won't be impacted, but clients doing more complex
counting are going to have to sprinkle in some .intValue() calls.
not filled with ideas on how to programmatically verify that the primary key
migration I've just created a test for is actually working. I can visually
inspect the logging output, but that's not useful for catching potential future
regressions.
from Nathan). If we need to add our primary key, we do so, if we need to remove
it, we do so, and only then do we consider whether we need to migrate it (in
which case we drop and re-add it).
1. DateFuncs.dayOfWeek and dayOfMonth can now be used on Timestamp. +FromDate
variants exist for using on Date.
2. hour, minute, second, etc. are now typed Number to cope with differing
opinions on the part of the underlying SQL drivers as to whether to return
Double, Long, Integer or something else.
Michael Bayne