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 <mgentr..asslight.net> 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 <andru..bjectstyle.org> 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
>>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Sun Jul 11 2010 - 14:52:45 UTC