*) We do not currently invalidate cached keysets even when we know for a fact that the associated records have changed (and exactly how they've changed). By storing along with each cached keyset the query datastructure that was used to fetch the keys, we can use the SQLExpression evaluator to do a secondary invalidation sweep over the records when they're requested and make sure they still match the WHERE clause of the original query. If they don't, we toss'em from the cached keyset. This basically means we can trust our cached keysets much more and increase the amount of time we keep them around in the cache.
*) Extending the first idea, we can do more than lazily invalidate parts of cached collections. We can, in fact, automatically adjust every relevant cached collection each time a record is deleted, inserted or modified. In theory, we could guarantee perpetual veracity of all cached collection queries. It's not a given that this is in every way a good idea, but it's a very interesting one to investigate.
As part of this change, ExpressionVisitor methods have to return a value. Slightly less elegant, but of greater general utility.
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.
Michael Bayne