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:
Par Winzell
2007-10-18 01:50:11 +00:00
parent 7bb36afef0
commit 1dd1b52d3f
2 changed files with 2 additions and 3 deletions
@@ -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;