Castor fails to save related object id with parent object when using MAX id generator on child object

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 0.9.4
  • Fix Version/s: 1.3.1
  • Component/s: JDO queries
  • Labels:
    None
  • Environment:
    Operating System: Windows 2000
    Platform: PC
  • Bugzilla Id:
    1160

Description

When I try to set up a parent/child relationship using jdo, the id for the
child object isn't stored in the parent's table like I would expect it to, but
only when I use key-generator in the mapping for the child class. If I were to
generate the id for the child class in code, it saves it to the parent's
related_id field fine. I think that the id isn't being generated for the child
class before the save for the parent class takes place and so there is no id to
save in the field, which is why it works if I generate the id in code. I'm
doing the saves in what I think are different transactions so I can't see how
the id for the child isn't already generated (the child is saved fine).

I will attach a file in a minute that has the JUnit test, mapping and database
files in it so you can see how I'm doing this.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Dan Daugherty added a comment -

Created an attachment (id=202)
Jar with unit test to reproduce the bug.

Show
Dan Daugherty added a comment - Created an attachment (id=202) Jar with unit test to reproduce the bug.
Hide
Permalink
Dan Daugherty added a comment -

Created an attachment (id=203)
I forgot some classes that were needed.

Show
Dan Daugherty added a comment - Created an attachment (id=203) I forgot some classes that were needed.
Hide
Permalink
Werner Guttmann added a comment -

I wonder a) whether this is still an issue, and b) where the attachements mentioned above have disappeared to ?

Show
Werner Guttmann added a comment - I wonder a) whether this is still an issue, and b) where the attachements mentioned above have disappeared to ?
Hide
Permalink
Ralf Joachim added a comment -

Test case reattached from bugzilla.

Show
Ralf Joachim added a comment - Test case reattached from bugzilla.
Hide
Permalink
Ralf Joachim added a comment -

The issue described does still happen. I therefore refactored the test case from zip file to better understand what's going on. Situation is as follows:

  • Entity2 has ID and name.
  • Entity1 has ID and a reference to Entity2

What happens in the test case is that an Entity2 instance is created in an own transaction. After that an Entity1 instance is created in a separate transaction which references to the Entity2 instance created previously. At the creation of the Entity1 instance the strange things happen depending on some conditions:

  • If Entity2 instance is loaded in the transaction that creates Entity1 everyting works as expected. After commit of the transaction Entity1 still holds the reference to Entity2 and this reference is also persisted to database. When Entity2 instance is loaded in the transaction the behaviour is independent of whether an key generator is used for Entity2 or not.
  • If Entity2 does not get loaded in the transaction that creates the Entity1 instance the result depends on whether we use a key generator for Entity2 or not. If we set ID of Entity2 ourself and do not use a key generator, after commit Entity1 still holds the reference to Entity2 and this reference is also persisted to database.
  • If we do not load Entity2 instance in the transaction that creates the Entity1 instance and ID of Entity2 is created by a key generator, after commit Entity1 still holds the reference to Entity2 but this time the reference is not persisted to database.

While it also would be an option to throw an exception at db.create() if the entity to be persisted refers to an detached entity, I think it would be better to search why the reference do not get persisted when a key generator is used for the referenced entity.

Any other opinions?

Show
Ralf Joachim added a comment - The issue described does still happen. I therefore refactored the test case from zip file to better understand what's going on. Situation is as follows:
  • Entity2 has ID and name.
  • Entity1 has ID and a reference to Entity2
What happens in the test case is that an Entity2 instance is created in an own transaction. After that an Entity1 instance is created in a separate transaction which references to the Entity2 instance created previously. At the creation of the Entity1 instance the strange things happen depending on some conditions:
  • If Entity2 instance is loaded in the transaction that creates Entity1 everyting works as expected. After commit of the transaction Entity1 still holds the reference to Entity2 and this reference is also persisted to database. When Entity2 instance is loaded in the transaction the behaviour is independent of whether an key generator is used for Entity2 or not.
  • If Entity2 does not get loaded in the transaction that creates the Entity1 instance the result depends on whether we use a key generator for Entity2 or not. If we set ID of Entity2 ourself and do not use a key generator, after commit Entity1 still holds the reference to Entity2 and this reference is also persisted to database.
  • If we do not load Entity2 instance in the transaction that creates the Entity1 instance and ID of Entity2 is created by a key generator, after commit Entity1 still holds the reference to Entity2 but this time the reference is not persisted to database.
While it also would be an option to throw an exception at db.create() if the entity to be persisted refers to an detached entity, I think it would be better to search why the reference do not get persisted when a key generator is used for the referenced entity. Any other opinions?
Hide
Permalink
Ralf Joachim added a comment -

Having said that i do not have any idea why using a key generator for the refered entity influences creation of the refering entity.

Show
Ralf Joachim added a comment - Having said that i do not have any idea why using a key generator for the refered entity influences creation of the refering entity.
Hide
Permalink
Ralf Joachim added a comment -

Final patch.

Show
Ralf Joachim added a comment - Final patch.

People

  • Assignee:
    Ralf Joachim
    Reporter:
    Dan Daugherty
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: