search

surinder-insonix / datanucleus-appengine

Automatically exported from code.google.com/p/datanucleus-appengine
0 stars 0 forks source link

Version not set on elements of Collection when loaded #308

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
When we load an object which has a Collection field, and both this object and 
the element have a version, the version is not set on the Collection element 
objects.

Original issue reported on code.google.com by googleco...@yahoo.co.uk on 29 Nov 2012 at 7:43

GoogleCodeExporter commented 8 years ago 
SVN trunk fixes this (get the source and build using "mvn clean install" to 
make use of it)

Original comment by googleco...@yahoo.co.uk on 29 Nov 2012 at 7:45

GoogleCodeExporter commented 8 years ago 
Does this also fix a similar problem where the VERSION isn't set on a plain 
@Entity if it is retrieved via a query, but it is if it is retrieved by find()?

Also, in the case of an entity with a collection, does the version on the main 
object still get updated and written, despite this object not being modified 
(not that this is as serious a problem)?

Thanks

Original comment by jonty.la...@gmail.com on 30 Nov 2012 at 1:21

GoogleCodeExporter commented 8 years ago 
OK, having retrieved and installed the relevant patch I can answer the first of 
my questions: yes it does.

The second one is also a yes, indicating that this oddity still exists. I 
wouldn't have thought it is a very big deal, but it is wrong I believe.

Just to be a bit clearer, suppose you have an entity instance A with a 
collection field of a couple of Bs, then you retrieve a detached copy of A and 
then another one, update the first B in the first copy of A and the second B in 
the other copy of A, then merge both As back one after the other.

The versions of the two B instances are now correctly updated, as expected 
without a clash, but something a bit strange happens to the version of the A. 
After each of the merges the A.version in the database has been incremented. If 
both detached copies have A.version == 1 then after the first merge the 
returned newly detached object has A.version == 2, as does the store, which is 
normal. If you merge the second copy, which still has A.version == 1, then 
instead of getting a optimistic lock exception it just goes through OK and the 
returned detached object now has A.version == 3, as does the store.

Given that A hasn't been changed I don't understand why it's being written back 
anyway, unless for some reason OPTIMISTIC_FORCE_INCREMENT has been used without 
requesting it (which is within the JPA spec I guess). However I don't 
understand why the second merge doesn't generate an exception. The version 
field holds 1, the store has 2, surely it shouldn't just quietly set them both 
to 3 at the end of the operation?

Or maybe I'm missing something.

Original comment by jonty.la...@gmail.com on 30 Nov 2012 at 3:08

GoogleCodeExporter commented 8 years ago 
If you don't override equals/hashCode of an element of a collection how is a 
persistence solution to know that the elements are not changed? The test I 
added doesn't have updates of the Main object. At the end of the day this issue 
is the retrieval of the version field, and that is what it fixes. If you have 
some other issue then its to you to provide a testcase (preferably using 
existing classes in GAE plugin) that demonstrates something

Original comment by googleco...@yahoo.co.uk on 30 Nov 2012 at 8:37