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 Fri, 06 Jul 2007 17:52:36 GMT
Hi Daniel,

The spec has several strategies for generating keys. Sorry for the  
bad formatting; copy/paste from 9.1.9:
public enum GenerationType { TABLE, SEQUENCE, IDENTITY, AUTO };
TheTABLEgeneratortypevalueindicatesthat thepersistenceprovidermust  
assignprimarykeysfor
the entity using an underlying database table to ensure uniqueness.
TheSEQUENCEandIDENTITYvaluesspecifytheuseof adatabasesequenceor  
identitycolumn,
respectively.

If you use IDENTITY, the database generates a unique key per table.  
If you use SEQUENCE, you can use the same SEQUENCE for multiple  
tables. If you use TABLE, the persistence provider manages a table of  
keys and you should expect that OpenJPA would use a single row to  
manage the keys for all of the classes that need to be unique.

Craig

On Jul 6, 2007, at 5:00 AM, Daniel Migowski wrote:

> Hello Craig,
>
> thank you for your answer. Could you clarify what you mean with  
> provider-generated id?
>
> With best regards,
> Daniel Migowski
>
> Craig L Russell schrieb:
>> 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!
>>
>
>
> -- 
>  |¯¯|¯¯|    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