I made a mistake originally allowing IDENTITY value generators some partial configuration (e.g. start value and increment value). This only ever worked on PostgreSQL, and so would cause completely different behaviour under MySQL. That's obviously a bad idea.
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.
This commit is contained in:
@@ -46,8 +46,7 @@ public class IdentityValueGenerator extends ValueGenerator
|
||||
public void init (Connection conn, DatabaseLiaison liaison)
|
||||
throws SQLException
|
||||
{
|
||||
liaison.initializeGenerator(
|
||||
conn, _dm.getTableName(), _fm.getColumnName(), _initialValue, _allocationSize);
|
||||
// identity value generators are auto-created by the database
|
||||
}
|
||||
|
||||
@Override // from ValueGenerator
|
||||
|
||||
@@ -53,7 +53,7 @@ public abstract class ValueGenerator
|
||||
public abstract boolean isPostFactum ();
|
||||
|
||||
/**
|
||||
* Prepares the generator for operation.
|
||||
* Ensures the generator is prepared for operation, creating it (only) if necessary.
|
||||
*/
|
||||
public abstract void init (Connection conn, DatabaseLiaison liaison)
|
||||
throws SQLException;
|
||||
|
||||
Reference in New Issue
Block a user