openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jody Grassel (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-1061) Entities extending from a Mapped Superclass that defines the ID fields share the same ObjectID type parameter
Date Tue, 05 May 2009 18:28:30 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706137#action_12706137
] 

Jody Grassel commented on OPENJPA-1061:
---------------------------------------

What seems to be happening is that during entity enhancement, the MSC type acquires an ObjectIDType.
 When the enhancer reaches the entity types extending the MSC, the if-block:

if (_meta.getIdentityType() == ClassMetaData.ID_APPLICATION
            && (_meta.getPCSuperclass() == null || getCreateSubclass() ||
                _meta.getObjectIdType() !=
                    _meta.getPCSuperclassMetaData().getObjectIdType())) {

compares the entity type's ObjectIDType with its MSC, finds they are equivalent, so the entity
enhancement does not add the app-id methods; the leaf entity types defer to the MSC's app-id
methods.  So when a new entity is being inserted into the persistence context, its initial
ObjectID has the MSC in its type field, instead of the leaf entity type.  If another entity
extending from the same MSC has the same PK-value, OpenJPAId's implentation of equals() will
think it is equivalent, failing the checkForDuplicateId() check.

I've included a potential fix for the above issue.  It adds an additional check, looking for
PKFields that are defined by a MSC.  If it finds such PKFields, it walks up the inheritance
tree, stopping at either the MSC defining the PKField, or at an entity type (to avoid breaking
entity inheritance mechanisms).  Stopping at the MSC defining the PKField qualifies the entity
type for app-id method inclusion during enhancement.  This way, the leaf entities use their
own pcNewObjectIdInstance() methods (with the appropriate type coded into the method) instead
of relying on the mapped superclass's version of the method.

However, there is a degree of uncertainty I have with the fix.  While it fixes the described
problem, and it does not fail any of the existing JUnit tests, I rely on the ClassMetaData.isEmbeddedOnly()
method to determine if a type is a MSC or a genuine entity.  From what I could tell, the ClassMetaData.setEmbeddedOnly()
method is called only during annotation and ORL XML metadata processing (it is set explicitly
false for MappedSuperClass types).  However, the methods ClassMetaData.isEmbeddedOnly() and
ClassMetaData.resolveMeta() are capable of mutating the ClassMetaData._embedded field; so
there needs to be verification that relying on the _embedded field is the correct method of
identifying a MSC type for this processing.


> Entities extending from a Mapped Superclass that defines the ID fields share the same
ObjectID type parameter
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1061
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1061
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa
>    Affects Versions: 1.2.0, 1.2.1
>            Reporter: Jody Grassel
>            Assignee: Jody Grassel
>         Attachments: unitttest.patch
>
>
> When a mapped superclass (MSC) defines @Id fields, it appears that entities extending
the MSC use the MSC's type in the generated ObjectID's type field.  This can result in unexpected
primary key collissions between entities that are not intended to be related in an entity
inheritance hierarchy.  Attached to the JIRA is a junit test case that demonstrates the problem.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message