dangerous. The "key" (which identifies the rows you want to change) was
[ColumnExp, Comparable, ...] and the data that you would be changing was
[ColumnExp, Object]. So if you happened to pass a comparable object as the
first value you wanted to change, say:
updatePartial(FooRecord.class, FooRecord.FOO_ID, 5, FooRecord.BAR_ID, 6,
FooRecord.BAZ, "biffle")
the compiler would think you wanted to use FOO_ID and BAR_ID as a key rather
than FOO_ID as a key and BAR_ID as something to be updated. Either way, it's
not clear what you want, so it should go. Now you have to create a Key():
updatePartial(new Key<FooRecord>(FooRecord.clsas, FooRecord.FOO_ID, 5,
FooRecord.BAR_ID, 6),
FooRecord.BAZ, "biffle")
or
updatePartial(new Key<FooRecord>(FooRecord.clsas, FooRecord.FOO_ID, 5),
FooRecord.BAR_ID, 6, FooRecord.BAZ, "biffle")
None of our code was doing this anyway. We were already using Key everywhere or
the (Class, Comparable) method for records with a single column as primary key.
* No more CacheBins, operations happen directly on the adapter.
* Each cache write must supply a CacheCategory value that identifies its type. Current values are RECORD, KEYSET and RESULT. We will probably need a MISC or USER or something along those lines, too.
The EHCache adapter has been entirely rewritten:
* Each CacheCategory maps to one EHCache, which means there are only a very few EHCaches, and we know what they are. We expect these to be declared in ehcache.xml rather than programmatically generated as before.
* Elements inside each EHCache are indexed by (cacheId, elementKey) tuples.
The main purpose of this refactor is to sort all Records into a single EHCache, which we can then make really, really large, and then let the LRU mechanism sort out what should be in memory and what shouldn't. The previous implementation would make no ram allocation distinction between busy records and ones rarely read.
SelectClause in there as well, but peskily two things on MSOY are using it to
do subselects. I'd prefer there was some less "reaching into the internals" way
to do subselects.
down (well, all the way to the public API anyway).
Revamped index creation while I was in there because that was one of the big
string users. Now you just put @Index on the field you want indexed, and if you
want a multi-column index you do things with a magical static method just like
we do for complex (function) indices.
@UniqueConstraint may still go away since it's basically exactly the same thing
as @Index(unique=true), so it's kind of pointless to support both.
- HSQL doesn't have full text search, so we just OR up a bunch of LIKE conditions to catch any and all matches. This is not efficient, but it'll do just fine for things like unit tests and development work.
- HSQL doesn't have & and |, it calls them BITAND and BITOR.
- HSQL doesn't have MySQL's unix_timestamp() or a way to get an 'epoch' from a date like PostgreSQL, so we count the number of seconds since 1970-01-01. I have not investigated to make sure this is exact, but it should at least be internally consistent.
- HSQL has a very neat list of data types that (no surprise) map very well to Java types.
Par Winzell