Issue Details (XML | Word | Printable)

Key: NUCRDBMS-488
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Unassigned
Reporter: yuri
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

Cannot delete an instance if it has @Version in @MappedSuperclass

Created: 16/Jan/11 03:15 AM   Updated: 23/Jan/11 11:53 AM   Resolved: 16/Jan/11 09:57 AM
Component/s: None
Affects Version/s: 2.2.0.release
Fix Version/s: 2.2.2, 3.0.0.m1

File Attachments: 1. Zip Archive JPATest.zip (3 kB)
2. Zip Archive JPATest2.zip (4 kB)

Environment: Ubuntu 10.04 64 bit

Datastore: PostgreSQL
Severity: Development


 Description  « Hide
When a @Version is declared in @MappedSuperclass, creating an instance succeeds, but deleting fails with stack trace shown below.

The same failure occurs if the version is defined in the super class that uses JOINED strategy. It will more likely occur for other inheritance strategies, but I haven't investigated this.

The version of the object extracted from the database is correct (the field value in the debugger). The problem occurs because the code in PersistentClassROF.getObjectForApplicationId() calls AbstractClassMetaData.getVersionMetaData() for a concrete class, and getVersionMetaData() returns null because the concrete class does not have @Version field annotation: the annotation is declared in the @MappedSuperclass

When getVersionMetaData() returns null, the execution skips the code that assigns the version number to ObjectProvider (sm), even though sm.myPC (the fetched object) has the correct version number.

I will be checking Hibernate if it correctly processes @MappedSuperclass and @Inheritance I'll consider switching to Hibernate because declaring @Version in concrete classes is tedious when there are many entities in the application.


yuri made changes - 16/Jan/11 03:17 AM
Field Original Value New Value
Attachment JPATest.zip [ 11334 ]
yuri added a comment - 16/Jan/11 03:29 AM
Attaching the stack trace:

----------------------------------------------------------------------
javax.persistence.RollbackException: Transaction failed to commit
at org.datanucleus.jpa.EntityTransactionImpl.commit(EntityTransactionImpl.java:120)
at org.datanucleus.test.Main.main(Main.java:62)
Caused by: javax.persistence.PersistenceException: Object with id "1" in table "jpatest"."B" has no version set on the object in memory and you want to delete it!! Please report this bug to the developers of DataNucleus with a way of reproducing it
at org.datanucleus.jpa.NucleusJPAHelper.getJPAExceptionForNucleusException(NucleusJPAHelper.java:287)
at org.datanucleus.jpa.EntityTransactionImpl.commit(EntityTransactionImpl.java:118)
... 1 more
Caused by: org.datanucleus.exceptions.NucleusException: Object with id "1" in table "jpatest"."B" has no version set on the object in memory and you want to delete it!! Please report this bug to the developers of DataNucleus with a way of reproducing it
at org.datanucleus.store.rdbms.request.DeleteRequest.execute(DeleteRequest.java:291)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.deleteTable(RDBMSPersistenceHandler.java:494)
at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.deleteObject(RDBMSPersistenceHandler.java:463)
at org.datanucleus.jdo.state.JDOStateManagerImpl.internalDeletePersistent(JDOStateManagerImpl.java:4448)
at org.datanucleus.jdo.state.JDOStateManagerImpl.flush(JDOStateManagerImpl.java:4798)
at org.datanucleus.ObjectManagerImpl.flushInternal(ObjectManagerImpl.java:3179)
at org.datanucleus.ObjectManagerImpl.flush(ObjectManagerImpl.java:3119)
at org.datanucleus.ObjectManagerImpl.preCommit(ObjectManagerImpl.java:3260)
at org.datanucleus.ObjectManagerImpl$2.transactionPreCommit(ObjectManagerImpl.java:324)
at org.datanucleus.TransactionImpl.internalPreCommit(TransactionImpl.java:394)
at org.datanucleus.TransactionImpl.commit(TransactionImpl.java:279)
at org.datanucleus.jpa.EntityTransactionImpl.commit(EntityTransactionImpl.java:106)
... 1 more

yuri added a comment - 16/Jan/11 04:05 AM
I added a new method to AbstractClassMetaData (in CORE) and replaced all calls off getVersionMetaData() with the calls of the new method in PersistentClassROF (in RDBMS). This seems to fix both of problems related to @Version in (@MappedSuperclass and @Inheritance JOINED).

I'm not sure if this is a correct fix though.


    public final VersionMetaData getVersionMetaDataForInheritanceChain() {
     VersionMetaData vmd = versionMetaData;
     if(vmd == null && pcSuperclassMetaData != null) {
     vmd = pcSuperclassMetaData.getVersionMetaDataForInheritanceChain();
     }
     return vmd;
    }

yuri added a comment - 16/Jan/11 05:12 AM
create/modify/remove test for @MappeSuperclass and @Inheritance JOINED that works with my changes.

yuri made changes - 16/Jan/11 05:12 AM
Attachment JPATest2.zip [ 11335 ]
Andy Jefferson added a comment - 16/Jan/11 09:57 AM
That test finally provides something reproduceable. SVN for 2.2 and 3.0 pass.

As far as you switching to Hibernate that is your decision and, since you make no financial contribution to this project, makes no difference to us. Needless to say, switching to software that has more than 2300 open issues would be a very interesting decision for you to make :-)

Andy Jefferson made changes - 16/Jan/11 09:57 AM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 2.2.2 [ 11127 ]
Fix Version/s 3.0.0.m1 [ 11062 ]
Resolution Fixed [ 1 ]
yuri added a comment - 16/Jan/11 03:59 PM
Andy, I think I'm fine with my fix for now, but I'll be considering the alternatives if I run into more issues. It's more important for me how many issues I run into as opposed to how many issues the product has (which usually depends on the number of product's clients).

It is also important how the issues are treated. This particular issue spreads across several products, has been around for years, and has been reported several times:

http://www.jpox.org/servlet/forum/viewthread_thread,4722
http://www.datanucleus.org/servlet/forum/viewthread_thread,5910

yet the requests were ignored. I also provided your team with exact steps on how to reproduce the issue:

http://www.datanucleus.org/servlet/jira/browse/NUCJPA-100

yet the steps were ignored and the issue was closed.

When people run into issues, they contribute their time helping your team to resolve the issues and improve the product, which ultimately attracts more clients who contribute financially to the product. I'm sorry to hear that you don't consider this as a viable contribution.

Andy Jefferson added a comment - 16/Jan/11 04:16 PM
Not sure why I bother replying but anyway. Your NUCJPA-100 was marked as not reproducible for a reason ... I ran it here on both versions of your test and it showed no error for me (on current code, using my datastores, on my hardware, and my build system (M2 - amply defined in the link provided). I ran the example in *this* issue (which has more model classes - crucial for the problem) and it demonstrated something that I can see (hence why *I* fixed it, with my updates - you provided no patch).

You linked two forum posts. Neither of which provided a reproducible definition of the problem; please check the facts. So since nothing was reproducible (from either ,nor your first one), then it is undefined how long it "has been around".

DataNucleus commercial support is there for people who can't fully demonstrate something, hence requiring assistance. Anyone not wishing to go that way get the simple "guarantee" that are clearly written on this (free) forum, for this (free) software. So with this in mind, yes please do consider your alternatives.

Regards

yuri added a comment - 16/Jan/11 04:43 PM
Andy, of course you fixed it, I'm not going to still that from you... I only provided you with the info on where to fix and how to fix. But I cannot guarantee that what I provided has no side effects because I only gazed at the code for a couple of hours and don't have your expertise related to this product under my belt.

Andy Jefferson made changes - 23/Jan/11 11:53 AM
Status Resolved [ 5 ] Closed [ 6 ]