load or modify the rows that match those keys" pattern so that we can almost
always just magically do the right thing with regard to the cache. Added a
version of deleteAll() that makes use of this.
Also nixed a bunch of checked exception tomfoolery which was almost entirely
unnecessary and now with DatabaseException is completely unnecessary.
A few things remain to be done:
- PrimaryKeySet tries to be "smart" if its passed 0 keys and use
LiteralExp("false") but that causes things to freak out because Depot then
doesn't know what primary class it's dealing with. I'm probably going to make
All and None expressions that match all and none of the records in a table
respectively.
- deleteAll() doesn't currently split its keys into chunks small enough to be
digestible by the database if we match more than 32,768 rows. I'll see if I
can't abstract out that code from FindAllQuery so that we can easily use it
everywhere. It would be cool to handle that a a lower level and allow the
WhereClause to say that it needs to be run in phases, but that would probably
complicate the crap out of the low-level code.
- I need to create PrimaryKey to go between Key and PrimaryKeySet so that we
can avoid duplicating the primary key columns thousands of times in a large
PrimaryKeySet.
of a checked exception. Invariably, we don't do anything with our
PersistenceExceptions except let them percolate all the way to the top and then
log a warning. We can probably automate the process of logging a warning with
useful information and save ourselves the trouble of doing it manually
everywhere.
1. Schema version is now always required. The "support" for unversioned schemas
was half-baked anyway.
2. Migration and table creation is now done in such a way that multiple
processes can start up and won't step on one another as they all try to migrate
the same schemas. Instead one will get a lock and do the migration and the
others will patiently wait.
This adds extra params around a bunch of things. I'll let the gods of Depot
sort that out.
BTW: Arithmetic.Div is still totally broken. It somehow booches the prepared
statement. I tried changing the operator String to "//" and that sorta worked,
but then the next operator over was missing...
I'm working around this using Mul, but it'd be nice..
So, IdentityValueGenerator's init() was meant only to be called upon table creation, but in r2234 I began calling it in all of a table's generators after every auto-migration. Needless to say this was bloody stupid, and caused MemberRecord's primary key generator to reset in production just now.
My fix is not to revert r2234, however, but to explicitly state init()'s expected behaviour: it should certainly not reset a generator if it already exists, but only ensure that it's operational -- creating it only if necessary.
We now never reset an IDENTITY generator, ever. The whole point of them is, after all, that they're auto-created by the database.
because those will have their values set at insertion time and the database
might rightly freak out about the inconsistency of saying that the field has a
constant default value.
Michael Bayne