Can you control the order of committing to the database when you have a collection of entities? I have an EVENT entity which has several self-references. It contains a reference to a PARENT_EVENT and a PRIOR_EVENT.
I previously had the program working where every creation of a new event was committed to the database and life was good but slow. No new event was ever commited to the database that didn’t already have a parent and prior event created. However, my list of events is going to be huge in any program run and I would prefer to not make thousands or tens of thousands of database commits if I don’t have to. I would prefer to do all of my event creation and manipulation in memory, and then commit the full list of events at the end.
When I code that using either dataManager or entityManager, I can’t control the order of which entities are committed. In the ListArray that I send to the commit, they are in the proper order, but I get “Integrity Constraint Violation: Foreign Key no parent” errors because the commit is processing later events first (an event is created before its’ PRIOR_EVENT is created). Is my best option to maintain individual commit calls to the database for each event as they are created or can I somehow control the order of commits?
I have the same issue as the above. I have a hierarchy with a parent and some 1 to many children. After two days of trying to solve this “elegantly” with the framework, I’m ready to try any hack or less elegant approach.
I’m about to temporarily temporarily remove the children (three separate 1 to many lists), commit the parent, add the children, and commit the parent again inside a onBeforeCommitChanges() method. Is this the best approach?
@clint.dalton If memory serves (and it may not), I think I abandoned the attempt to use bulk commits at the end of my processing routine and instead reverted to individual commits during my processing routine (whenever an event was created). This has a performance impact if you have a lot of commits but it was acceptable in my case. Because I was doing this sequentially, I never had a later event referring to a prior event that hadn’t already been committed.
I think Andrey’s recommendation to do two bulk commits should work as well. First commit all your entities without the problematic relationships. Than commit again after the relationships have been established. That way, the 2nd commit is only updating a relationship between entities that already exist, rather than trying to create the entities at the same time.