<< Back to previous view

[NUCDBFO-24] SCO wrapped fields are persisted sometimes Created: 20/Aug/08  Updated: 09/Sep/08

Status: Open
Project: DataNucleus Store DB4O (ARCHIVED)
Component/s: None
Affects Version/s: 1.0.0.m4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Roel Stolker Assignee: Unassigned
Resolution: Unresolved Votes: 0

File Attachments: Zip Archive Test.zip    
Datastore: DB4O

 Description   
Happens when nesting objects of the same type in an Hashtable. For example;

We have an A object with an children Hashtable containing two other A objects:

A
|
children - A
                  |
                  children

                - A
                   |
                   children

A a = new A();
A child1 = new A();
A child2 = new A();
a.addChild(child1);
a.addChild(child2);


After persisting "a" to the datastore we give "child2" a child:

A
|
children - A
                  |
                  children

                - A
                   |
                   children - A
                                     |
                                     children

child2_1 = new A();
child2.addChild(child2_1);


So now there's a child on the second level. We persist this again to update the changes.


Looking at the datastore some new objects of the following types are added:
org.datanucleus.sco.simple.Hashtable
org.datanucleus.identity.DatastoreUniqueOID

It also appears that there are 6 A objects instead of 4. I think this is because DB4O persists the A objects with SCO fields as new objects. Also when reading back the first A object the A object "child2_1" is missing.

Looking at updateObject in DB4OPersistenceHandler it seems that the call to replaceAllLoadedSCOFieldsWithValues does not unwrap the SCO fields on the second level.
 

 Comments   
Comment by Roel Stolker [ 20/Aug/08 03:50 PM ]
Testcase added.
Comment by Roel Stolker [ 09/Sep/08 08:48 AM ]
Concerning the persisted DatastoreUniqueOID objects.

It seems that the jdoDetachedState field of a PC has the DatastoreUniqueOID object after detaching. When updating this PC with updateObject DB4O sees this object as a new object because we set the OID in the jdoDetachedState array. This results in writing the PC as a new object in the datastore, causing a duplicate.

Generated at Sun Dec 21 21:10:30 CET 2014 using JIRA 4.0#466.