One more stupid question about DomainObjects framework...
Here is business logic excerpt behind the problem:
- there is hierarchy of Level1, Level2, Level3 objects (e.g. Level1 has collection of Level2, Level2 has collection of Level3 in its turn, Level3 is the leaf node of hierarchy)
- Level1.ClsLevel2[i] must be removed (please note that there is Level3 instance referenced to Level1.ClsLevel2[i])
Q. : What is the correct way of persisting such data modification? Is it possible afterall?
PS.: I was trying different things to make it working:
- playing with CascadeStore/CascadeDelete attributes in .xml (CascadeDelete true/false gave same results, err...no results)
- calling RemoveAllLevel2FromLevel1 (this is autogenerated method name responsible for collection "removes") on Level1 object with Level2 instance parameter (for some reason generates obscure Level1 update query)
- calling Delete on Level2 instance (here if I call BindToTransaction on Level1, reference between Level2 & Level3 screams about violation (only Level2 object is trying to be deleted))
Appreciate your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What is the correct way of persisting
> such data modification?
There are two ways to persist your object graph:
a. Explicitly bind all members of the graph to the current transaction via a call to BindUtil.BindToTransaction(). An example of this is in the unit test BuildAnObjectThroughDefaultConstructor(); you'll see on lines 83 and 84 calls to
b. Only bind the root object of the graph to the transaction and let DomainObjects automatically bing child objects in the graph to the current transaction by setting 'CascadeStore = true' in the Repository.xml CollectionDescriptors. You'll find an example of this in the unit test CascadeStoreCollectionModifiedOutsideContextOfTransaction(). On line 43 only the root object is bound to the current transaction:
// now persist the parent object
// (Note: CascadeStore == true on the SubTypes CollectionDescriptor)
PersistenceFacade.Persist(rootObject);
I'm not sure why your tests are not working. Are you able to create a unit test that could help me reproduce your issue? The DomainObjects tests in this area are passing...
Let's start with your CascadeStore issues and get them working, then we can discuss/investigate the your Delete tests if they are still not working.
Regards,
Richard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
One more stupid question about DomainObjects framework...
Here is business logic excerpt behind the problem:
- there is hierarchy of Level1, Level2, Level3 objects (e.g. Level1 has collection of Level2, Level2 has collection of Level3 in its turn, Level3 is the leaf node of hierarchy)
- Level1.ClsLevel2[i] must be removed (please note that there is Level3 instance referenced to Level1.ClsLevel2[i])
Q. : What is the correct way of persisting such data modification? Is it possible afterall?
PS.: I was trying different things to make it working:
- playing with CascadeStore/CascadeDelete attributes in .xml (CascadeDelete true/false gave same results, err...no results)
- calling RemoveAllLevel2FromLevel1 (this is autogenerated method name responsible for collection "removes") on Level1 object with Level2 instance parameter (for some reason generates obscure Level1 update query)
- calling Delete on Level2 instance (here if I call BindToTransaction on Level1, reference between Level2 & Level3 screams about violation (only Level2 object is trying to be deleted))
Appreciate your help!
Hi James,
> What is the correct way of persisting
> such data modification?
There are two ways to persist your object graph:
a. Explicitly bind all members of the graph to the current transaction via a call to BindUtil.BindToTransaction(). An example of this is in the unit test BuildAnObjectThroughDefaultConstructor(); you'll see on lines 83 and 84 calls to
BindUtil.BindToTransaction(simpleObject2);
BindUtil.BindToTransaction(child);
b. Only bind the root object of the graph to the transaction and let DomainObjects automatically bing child objects in the graph to the current transaction by setting 'CascadeStore = true' in the Repository.xml CollectionDescriptors. You'll find an example of this in the unit test CascadeStoreCollectionModifiedOutsideContextOfTransaction(). On line 43 only the root object is bound to the current transaction:
// now persist the parent object
// (Note: CascadeStore == true on the SubTypes CollectionDescriptor)
PersistenceFacade.Persist(rootObject);
I'm not sure why your tests are not working. Are you able to create a unit test that could help me reproduce your issue? The DomainObjects tests in this area are passing...
Let's start with your CascadeStore issues and get them working, then we can discuss/investigate the your Delete tests if they are still not working.
Regards,
Richard
Thanks Richard,
I've finally managed to get some time and build the sample (console app plus database script file with readme). How can I send it to you?
Can you please post it on the Patches tracker? I'll pick it up there and integrate it into the documentation.
Thanks James,
Richard
I've posted my example under the same subject(although it's not a unit test, but still it's fully functional console app).
Thank you for your time.