We've chosen not to conflate Java transience with Depot non-persistence. It's a
little wonky to have to choose a particular memory model behavior just to have
a field not persisted in your record.
@Transform is first sought on the field itself, which overrides any other
handling. Next it is sought on the class that represents the field (i.e. if the
field is type Foo we look for an @Transform annotation on class Foo). We avoid
doing this somewhat expensive search if the field has a type that we know
cannot have an @Transform annotation. If we've still found no @Transform
annotation (which is unfortunately the overwhelmingly common case), we then
create a stock marshaller.
Otherwise, if a data migration is registered and run after the initialization
process, we'll end up warning that this record has not yet been initialized.
In theory, you should register your data migrations prior to calling initRepos,
but I don't want to be too draconian about that. Unlike schema migrations, you
*could* conceivably mean to start your app up and let it run before running
data migrations.
This allows two separate services which share a database to assign "control" of
the schema to one of the services. The non-controlling service can be
configured to simply fail if new code is deployed to said service before new
code is deployed to the controlling service, rather than have the
non-controlling service migrate the schema out from under the controlling
service.
version is set to what we expect it to be.
Otherwise if one node reads an old value for the schema version, it will
be able to grab the migration lock as long as another node has already
completed the migration.
"order by null" can be used in a query with a "group by" in it to tell
the database to suppress the overhead of sorting the results.
(Supported in postgres and mysql.)
Changed the build visitors to have a whitelist of supported
Orders, and to NPE on a null value for the Order enum.
Note that previously "order by null" could be accomplished by passing
a null value to your OrderBy, but now the enum constant must be used.
I can change that if this disrupts anything.
I don't like to see the words "Aborting creation." when I'm in the middle of
creating databases. If we're not creating the index, fine, but don't give me
the idea that we're aborting the entire creation of the table.
- Added an IntegerIterable Transformer.
- Document that these *Iterable transformers work with List/Set/Collection...
In case it wasn't clear.
- Added a sizeHint argument to the createCollectionBuilder method, take
advantage of that in the IntegerIterable since we don't need to do any
work to find the size.