* 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.
something and then those needs went away and now it's just a marker that
differentiates arbitrary SQLExpression instances from those that represent
clauses of a query.
efficient.
Also switched from Collection to Iterable in some internal spots where we don't
need anything other than an iterator. I wanted to push this all the way out to
DepotRepository but ran into some snags. I'm leaving in this change in case I
feel like desnaggling the external bits later.
basic stats reporting and query and cache logging.
PersistenceContext no longer sticks its nose so deeply into the business of
Query and Modifier. It just passes itself along and allows them to do any cache
activity they need during their normal execution. The one situation where we
keep our nose in their business is to allow a Query to return a result from the
cache before it is even invoked so that we can avoid requesting a database
connection if we won't ever need one.
Par Winzell