Hmm, looking at the adapter code, it doesn't appear that our H2 adapter supports auto-increment PKs. That is my first mistake. :-) The logging is probably getting confused because the model specifies auto-increment, but the code/bind is not doing that.
mrg On Sun, Jul 11, 2010 at 10:33 AM, Michael Gentry <[email protected]> wrote: > A little background. I'm using an in-memory H2 database > (jdbc:h2:mem:cbe) and have CreateIfNoSchemaStrategy selected in the > model to create the schema in memory on startup. For my DbEntities I > had Database-Generated selected for the primary keys. In looking at > the logs, I noticed that the CREATE TABLE was not using AUTO_INCREMENT > though: > > CREATE TABLE Users (first_name VARCHAR(25) NULL, id BIGINT NOT NULL, > last_name VARCHAR(25) NULL, username VARCHAR(26) NULL, PRIMARY KEY > (id)) > > (I've simplified the model while debugging since the previous e-mail, > so role and password are missing.) > > Then while running, it was always selecting/updating the > AUTO_PK_SUPPORT table, even though I had specified to use database > generated keys: > > SELECT NEXT_ID FROM AUTO_PK_SUPPORT WHERE TABLE_NAME = 'Users' > UPDATE AUTO_PK_SUPPORT SET NEXT_ID = NEXT_ID + 20 WHERE TABLE_NAME = 'Users' > > > Then I went and switched primary key generation from database > generated to default (to use the AUTO_PK_SUPPORT table) and that > cleared up the logging: > > INSERT INTO Users (first_name, id, last_name, username) VALUES (?, ?, ?, ?) > [bind: 1->first_name:'Deborah', 2->id:201, 3->last_name:'Reeves', > 4->username:'dreeves'] > > I'm not sure if it is a problem with the H2 adapter or not. I suspect > (it has been years since I looked at the logging code) that the > logging looks to see if the PK is database generated and skips logging > it, which is throwing everything off. > > If I switch the primary key generation back to database generated, the > logging is like: > > [bind: 1->first_name:'Kevin', 2->last_name:203, 3->username:'Evans', > 4->username:'kevans'] > > So even though I removed two columns, the issue still manifests itself > when the primary key generation is set to database generated. > > mrg > > > > > On Sun, Jul 11, 2010 at 5:11 AM, Andrus Adamchik <[email protected]> > wrote: >> I haven't experienced that, but seems like a bug. Is it reproducible? >> >> Andrus >> >> On Jul 11, 2010, at 2:25 AM, Michael Gentry wrote: >> >>> Has anyone noticed/experienced the following logging anomaly in 3.0? >>> >>> >>> INFO: INSERT INTO Users (first_name, id, last_name, password, role, >>> username) VALUES (?, ?, ?, ?, ?, ?) >>> INFO: [bind: 1->first_name:'Wesley', 2->last_name:203, >>> 3->password:'Perry', 4->role:NULL, 5->username:NULL, >>> 6->username:'wperry'] >>> >>> >>> Bind parameter 2 is really "id", but for some reason it is listed as >>> "last_name" and things continue out of sync until the very end, when >>> "username" is listed twice. >>> >>> >>> Thanks, >>> >>> mrg >>> >> >> >
