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.
non-persistent type), and transform in getFromSet/writeToStatement, rather than
operate on T (the persistent type) and transform in
getFromObject/writeToObject.
This makes the newly added test in TransformTest work, rather than fail, as it
did previously.
safely be stored, but if rehydrated into a Set then an EnumSet would
be created and that can't store nulls.
So, check to see if the encoded String has any nulls in it and
have the builder create a HashSet instead.
so that partially constructed queries can be reused without any special care
being taken by the caller. I also switched to the use of a functional list
internally to make this whole process more pleasant and efficient.
pojos which hold the results of the query. The caller can decide if they want
to use the magic of selectInto(), and be careful not to screw up the types and
order of their pojo fields, or they can boil up some plates and create a
builder for their pojo, which will be type-checked, soup to nuts.
only on a matching public constructor. This version is not type-safe, but I'll
also be adding an additional mechanism to do selections like this that uses a
type-safe builder approach, which comes at the cost of a healthy dose of
boilerplate code.
This uncovered a lot of loose geese as far as the database was concerned, which
necessitated turning a bunch of functions which had specific type into
functions which have type Number.
In general, I made the Funcs/StringFuncs/MathFuncs factory methods provide an
expression typed Number and I left the underlying SQLExpression derivations
able to be more precisely typed. So if you know that your database does not
magically promote an integer column to long when calling sum() on it, you can
force a more specific type. But really, I don't see why you would go to the
trouble. You can just call intValue() on your result and get the int you were
looking for regardless of what the database thought it would be fun to provide.
I also fixed a few HSQLDB variants (average -> avg, round(a) -> round(a, 0),
etc.) and made notes about a few things that just plain don't work in HSQLDB.
Awesome! Fortunately they're things like log-base-10, rather than more critical
functionality.
exception. I'm tempted to reinstate the NoSuchElement exception for a load()
that attempts to project fields from the selected rows, but I think it makes
more sense for a load() which aggregates over zero rows to return null than to
throw a NoSuchElement exception.
Some examples:
int max = _repo.from(TestRecord.class).load(Funcs.max(TestRecord.RECORD_ID));
List<Tuple2<String,Integer>> data = _repo.from(EnumKeyRecord.class).
groupBy(EnumKeyRecord.NAME).ascending(EnumKeyRecord.NAME).
select(EnumKeyRecord.NAME, Funcs.count(EnumKeyRecord.TYPE));
Still no caching integration, but the ratio of utility over boilerplate is
high.
least on something that was Comparable, but unfortunately, the numeric type's
only shared supertype is Number and that is not comparable.
If I require Number, then you can't do greatest(timestamp, timestamp), and if I
require Comparable, then you can't do greatest(int, double) because the
compiler can't unify those types to something that is Comparable.
I could require that you only compare apples with apples (i.e. greatest(int,
int) or greatest(double, double)), but databases will happily compare
greatest(int, double) and people are going to want to do that. I could
introduce some sort of numeric conversion expressions, but I think that's
getting too deeply into the realm of type safety for type safety's sake.
fast-and-looseness by propagating types through foo.eq(bar) expressions,
foo.lessThan(bar) expressions and the like.
This means a few things stopped working, like
StringFuncs.length(MyRecord.BYTE_ARRAY_FIELD), but now there's
Funcs.arrayLength() for that. Also Date functions are looser than I'd like
because there's no supertype between sql.Date and sql.Timestamp (to express a
date having type) and sql.Timestamp and sql.Time (to express a time having
type). So you can still do some foot shooting with those methods, but it's
hardly worth crying over since the foot shooting range was fully open for
business prior to this.
MSOY fixes coming presently. ProjectX fixes shortly thereafter.
List<Tuple2<Integer,EnumKeyRecord.Type>> jdata =
_repo.from(TestRecord.class).
join(TestRecord.NAME, EnumKeyRecord.NAME).
select(TestRecord.RECORD_ID, EnumKeyRecord.TYPE);
This should eliminate the need for pesky one-off computed records when doing
ad-hoc joins.
1. ColumnExp is now parameterized on the type of the column it represents. This
enables item number two.
2. The beginnings of a very primitive implementation of individual field
selection, which looks like:
List<Tuple2<Integer,String>> results = from(FooRecord.class).where(
FooRecord.ID.in(someIds)).select(FooRecord.ID, FooRecord.NAME);
I don't advise using this new functionality just yet, because it's very
primitive and will probably break if you try to do anything fancy. Plus it
doesn't interact with the cache at all yet.
However, I wanted to get the typed ColumnExp bits in there so that I can
migrate all the existing projects over and get that painful business out of the
way. Note for the jumpy: migration in this case means eliminating a bunch of
unchecked type usage warnings, rather than behavioral changes. The existing
Depot functionality continues to work exactly as is. The types are not used
except for in the new individual field selection code.
One bit of code that will break is calls to updatePartial() which used to take
a Map<ColumnExp, ?> and now take a Map<ColumnExp<?>, ?>. Since those were
already in generics land, they won't just fail with an unchecked type warning,
the compiler will reject the old call (the calls are binary compatible, so
unrecompiled code will still work fine). Fortunately the Map-taking
updatePartial is not called that much outside of MSOY, which I have already
migrated to fully parameterized ColumnExp land.
having a separate deleteFrom(record).where(...).delete() builder, but
from(record).where(...).delete() was so much nicer that I decided that
preventing the specification of invalid clauses could be deferred from compile
to runtime.
I could do some fiddly things with return types and have from() return a
builder that then subsequently pigeon-holed you into deletability or not
depending on whether you called things like orderBy(), but to do so in Java
would require that I override every method to specialize its return type, which
presents something of a maintenance annoyance.
With this you can write queries like:
MaxPointsRecord max = from(MaxPointsRecord.class).
override(DailyScoreRecord.class),
where(DailyScoreRecord.KEY.eq(key)).load();
List<DailyLeaderRecord> top = from(DailyLeaderRecord.class).
override(DailyScoreRecord.class).
join(DailyScoreRecord.KNIGHT_ID, KnightRecord.KNIGHT_ID).
where(DailyScoreRecord.KEY.eq(key),
DailyScoreRecord.POINTS.eq(max.maxPoints)).
select();
After configuring your query, you can load(), you can select(), you can
selectKeys() and you can selectCount(). Other improvements include configuring
cache behavior (from(FooRecord.class).noCache().where(...).select()).
random() became randomOrder() because I think that seeing random() stuffed in
the middle of a query is insufficiently communicative.
Next, I'm going to look into extending the query builder to allow things like:
from(MemberRecord.class).
where(MemberRecord.CREATED.greaterThan(date)).
select(MemberRecord.AVATAR_ID, MemberRecord.HOME_SCENE_ID);
// yields List<Tuple2<Integer, Integer>>
which will require adding types to ColumnExp, which I hope to do in a
moderately backwards compatible way. If I can, I may use those types to enforce
type correctness and turn things like the following into a compiler error:
MemberRecord.MEMBER_ID.greaterThan("bob")
If I had a more sophisticated type system, I could even make an attempt to call
greaterThan() on a ColumnExp<String> a compilation error.
If the above doesn't turn out to be a rabbit hole extraordinairre (it probably
will), I'd like to look into obviating the need for most of the FieldOverride
and FromOverride fiddling, and support things like:
from(MemberRecord.class).
where(MemberRecord.CREATED.greaterThan(date)).
select(Exps.max(MemberRecord.SESSIONS));
// yields List<Integer>
which would take Depot in the direction of being a (somewhat) type safe wrapper
around SQL. This would go a long way toward bridging the conceptual gap between
"the SQL I know I want to write" and "how the fuck do I do this with this Java
API".
I don't think I'm going to be able to get too far with the type-safe wrapper
approach without propagating types all over the place, which may result in
backwards compatibility breakage. If things get really bad, I may just have to
pinch off the Depot 1.x series and venture into the green fields of Depot 2.x.
I'll see how far I can get before taking such drastic action, however.
Par Winzell