DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to.
DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued

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.

Description

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.

----------------------------------------------------------------------
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 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

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).

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;
}

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 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, 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:

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.

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,4722http://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.

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.

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

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.

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.