This causes the elements of the list to match the original order they were
added to the cons list (which stores elements "backwards").
This order matters for joins, as Ray discovered.
Most JDBC drivers have supported this for ages. No longer do we need the
hackery of turning around and doing another query to obtain generated key
values.
It would be extremely rare, but if two nodes were trying to simultaneously
store() the same record with the same Key, one could fail with a DKE.
Attempt a second 'update' if the insert fails.
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.
Ray Greenwell