- refactoring query construction;
- modified collection lookup to first look up the matching primary keys, then
check the cache for hits then look up the remainder from the database;
- other small renamery and cleanup.
don't freak out if a field is added, then renamed or retyped all in the same
migration. Now the column will be added with its proper name by the default
migrations and then the Rename migration will not freak out and the Retype
migration will NOOP.
- don't try to generate getKey() for abstract classes;
- get all of our class's fields, not just the ones declared in this class; do
so using ClassUtil.getFields() rather than Class.getFields() because the
latter returns the fields in a random order which is annoying whereas
ClassUtil.getFields() returns them in an intuitive order (declaration order
of the super-most class, then declaration order of the first derived class
and so on);
- use Field.getAnnotations() rather than Field.getDeclaredAnnotations() just
for consistency, even though you can't "override" a field and inherit
annotations from your parent class (but if someday we have annotated
PersistentRecord methods we'll want to use getAnnotations() not
getDeclaredAnnotations() so we should provide appropriate copy and paste
fodder).
we'll cache the introspected primary key fields and reuse them. This has the
added benefit that we can eliminate storing the key fields entirely because we
know they must be exactly the set of primary key fields for the object which
never changes.
We will have to ensure that we flush our caches whenever we do a new release,
but we would have to do that anyway for a variety of reasons. Actually, we
could perhaps make use of the persistent object's versions and note the version
number of the cached instances in the cache and ignore the cache if they
differ.
out when you try to compile code that calls a varargs method with more than one
class. At that point it tries to create an array with a generic element type
which is disallowed.
Michael Bayne