Michael Bayne
b8fec6cab5
When we go to bind values in an update statement, we either have:
- field names and a pojo from which to extract them, in which case
transformation happens naturally when we extract the current value from the
pojo
- value expressions (like 1, or "bob") which we were previously just binding
directly to the statement, which was wrong because they need to first be
transformed in the case where the field in question has an @Transform
annotation; now we get the field marshaller for the field in question and
pass the raw value to it, so that it can do the necessary transformations in
writeToStatement()
- other expressions (like LiteralExp("true") or or IntervalExp or anything else
where the database is involved in computing the final value to be assigned to
the column).
This last case still holds the potential for badness with regard to transformed
fields. We can't magically transform the value to be stored into a field if the
database is computing the ultimate value. Say, for a contrived example, that
you had a record where you stored an int column as a String for shits and
giggles:
public class MyRecord {
@Transform(IntToStringTransformer.class)
public int someValue;
}
someValue will be a string column in the database, owing to the
IntToStringTransformer converting the int to a String.
Now you come along and think to yourself, "Hey, I want to store the current
minute in my 'int' field." and you write something like:
updatePartial(MyRecord.class, MyRecord.SOME_VALUE,
DateFuncs.minute(Exps.literal(new Timestamp(System.currentTimeMillis()))));
Well, that's going to end up trying to stuff an int-valued expression (computed
by the database) into a String field, and the shit will hit the fan.
I can't really think of a non-contrived situation where this is likely to bite
us in the ass, but I don't especially like grass covered pits like this lying
around, waiting for someone to unsuspectingly step into them.
I could fail if you try to update a transformed field with anything other than
a ValueExp (or the current value from a pojo), but that would prevent you from
doing something potentially useful and safe like copying one field to another,
which both use the same transformation.
Depot Persistence Library ------------------------- Depot is a relational persistence library for Java. It is an ORM library, but has aims that are somewhat different from the popular "managed" persistence libraries like Hibernate and others. Website ------- See the Depot website for documentation and other info: http://code.google.com/p/depot/ Building -------- The library is built using Ant. It can be found here: http://jakarta.apache.org/ant/ To compile the code and generate a jar file, invoke: % ant dist Invoke 'ant -p' to see information on other build targets. Depot also provides .classpath and .project files for Eclipse users which require that you set an EXT_LIBS_DIR variable indicating the location of the external jar dependencies. The Depot Eclipse project also depends on the Eclipse project for the samskivert library. That library can be found at: http://code.google.com/p/samskivert/ License and Distribution ------------------------ Depot is released under the LGPL. This means you are free to use Depot on any project, open source or proprietary, but that any modifications made to the library must be made available to the maintainers. See COPYING for more detailed information. The most recent version of the Depot source code is available at the website listed above. $Id$