db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: Expected behavior of identity_val_local()?
Date Fri, 03 Feb 2006 17:11:04 GMT
Justin Patterson wrote:
> I Just added a dummy column with a default value as a workaround for now 
> and it's got me going (with hibernate) long enough to evaluate.

If you could summarize what you learned on the Derby Wiki, that might 
help others who are working with Hibernate:

http://wiki.apache.org/db-derby/HibernateHelp

just a thought,

  -jean

p.s. anyone can update the Derby Wiki page. You just need to login (link 
on the upper right of the page) and create a user profile.

> 
> Sorry for missing the bug report and generating extra noise!
> 
> Thanks!
> -Justin
> 
> Satheesh Bandaram wrote:
> 
>> This is DERBY-439 that has been marked as duplicate of DERBY-353 
>> <http://issues.apache.org/jira/browse/DERBY-353> and fixed in trunk. 
>> (10.2 release) Fix could be back-ported to 10.1, if you have the itch 
>> and need.
>>
>> Satheesh
>>
>> Justin Patterson wrote:
>>
>>> I'm working with Hibernate 3 and Derby 10.1.2.1 and some bad things 
>>> started happening (I just ported to Derby from One$DB).  I traced it 
>>> back to a behavior in Derby and I'm wondering if it's the expected 
>>> behavior or not.  I've simplified the condition below.
>>>
>>> CREATE TABLE test1 (
>>>  id INTEGER GENERATED ALWAYS AS IDENTITY
>>> );
>>>
>>> INSERT INTO test1 (id) VALUES (default);
>>> VALUES identity_val_local();
>>>
>>> DROP TABLE test1;
>>>
>>> This mimics what Hibernate is doing in my application.  I would 
>>> expect that identity_val_local() would return '1' here, but instead 
>>> it's set to NULL.  It seems to be related to the fact that there's 
>>> only one column and it's the identity column.  The reason that I say 
>>> this is because, if I create a table with another column, and insert 
>>> a record into it with the 'id' defaulted either explicitly or 
>>> implicitly (through omission), it works as I would expect.
>>>
>>> CREATE TABLE test2 (
>>>  id INTEGER GENERATED ALWAYS AS IDENTITY,
>>>  dummy SMALLINT
>>> );
>>>
>>> INSERT INTO test2 (id,dummy) VALUES (default,8);
>>> VALUES identity_val_local();
>>> INSERT INTO test2 (dummy) VALUES (8);
>>> VALUES identity_val_local();
>>>
>>> DROP TABLE test2;
>>>
>>> In this case it returns first '1' and then '2'.
>>>
>>> I saw that there were some conditions under which the value returned 
>>> by identity_val_local() was not affected, but I don't think that a 
>>> table with only one column that's the identity column was one of 
>>> those cases.
>>>
>>> Any advice is greatly appreciated.
>>>
>>> Thanks,
>>> -Justin
>>>
>>>
>>>
> 


Mime
View raw message