openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Identity Problem with MappedSuperclass
Date Thu, 05 Jul 2007 20:20:55 GMT
Sounds to me like there is a conflict with the identity type. With  
GenerationType.IDENTITY, the database assigns the identity and unless  
you have a real table representing the superclass, the database will  
assign each table its own sequence of guaranteed unique ids.

The solution might be to use a provider-generated id instead of a  
database-generated id.

Craig

On Jul 5, 2007, at 12:02 PM, Daniel Migowski wrote:

> Hi Patrick,
>
> thank you for all your answers. The exception is the following:
>
> <0.9.7-incubating fatal user error>  
> org.apache.openjpa.persistence.ArgumentException: Attempt to assign  
> id "1" to new instance "de.ikoffice.app.core.model.User-1" failed;  
> there is already an object in the L1 cache with this id. You must  
> delete this object (in a previous transaction or the current one)  
> before reusing its id.  This error can also occur when a  
> horizontally or vertically mapped classes uses auto-increment  
> application identity and does not use a hierarchy of application  
> identity classes.
>
> Subjects are the same classes as in my previous post, the Company- 
> User-relation. Oh, maybe thats the reason, too. I added the user  
> and wanted to persist it in one persist-Statement together with the  
> company. I have CASCADE=ALL set on the referencing User-Attribute.
>
> With best regards,
> Daniel Migowski
>
> Patrick Linskey schrieb:
>> Hi,
>>
>> We have test cases that demonstrate that distinct subtypes of a
>> @MappedSuperclass can share the same ID value [1], so the behavior
>> you're expecting should be possible in the general sense. Our test
>> case doesn't use GenerationType.IDENTITY, though.
>>
>> Can you post the exception that you're seeing and the  
>> corresponding SQL log?
>>
>> -Patrick
>>
>> [1] https://svn.apache.org/viewvc/openjpa/trunk/openjpa- 
>> persistence-jdbc/src/test/java/org/apache/openjpa/persistence/ 
>> inheritance/TestSharedMappedSuperclassIdValue.java?view=log
>>
>> On 7/5/07, Daniel Migowski <dmigowski@ikoffice.de> wrote:
>>> Hello OpenJPA users.
>>>
>>> Ich have the following Class hierarchie and want to define the id  
>>> (with
>>> @GeneratedValue(strategy=GenerationType.IDENTITY)) in the parent  
>>> class:
>>>
>>>  Base    <- @MappedSuperclass - defines an @Id-Field
>>>  /  \
>>> A    B   <- @Entity
>>>
>>> Now OpenJPA uses the same identity range for all thos objects,  
>>> even if
>>> the @Id-Field is not in an @Entity-Class but in a  
>>> @MappedSuperclass, and
>>> as such does not have a database equivalent.
>>>
>>> Expected behaviour is (and this is because the id fields get all  
>>> mapped
>>> in their own tables) that OpenJPA sees the fields of the mapped
>>> superclass as fields of the derived entites (in fact, the  
>>> superclass in
>>> not an entity at all) without any corellation between them.
>>>
>>> Is this a bug or intentional behavour? Do i really have to define  
>>> the
>>> field in the derived classes?
>>>
>>> Greetings,
>>> Daniel Migowski
>>>
>>
>>
>
>
> -- 
>  |¯¯|¯¯|    IKOffice GmbH             Daniel Migowski
>  |  |  |/|                            Mail: dmigowski@ikoffice.de
>  |  | // |  Nordstr. 10               Tel.: +49 (441) 21 98 89 52
>  |  | \\ |  26135 Oldenburg           Fax.: +49 (441) 21 98 89 55
>  |__|__|\|  http://www.ikoffice.de    Mob.: +49 (176) 22 31 20 76
>
>             Geschäftsführer: Ingo Kuhlmann, Daniel Migowski
>             Amtsgericht Oldenburg, HRB 201467

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message