please take a look at createExecution method in ExecutionImpl to verify if your fix is appropriate:
childExecution.save(); // make sure that child execution are saved before added to a persistent collection // cause of the 'assigned' id strategy, adding the childExecution to the persistent collection // before the dbid is assigned will result in identifier of an instance of ExecutionImpl altered from 0 to x addExecution(childExecution); // composeIds uses the parent so the childExecution has to be added before the ids are composed childExecution.composeIds();
After your fix composeIds will be called twice, my concern is if that will not cause us any troubles. It is better to double check it.
Thank you for reviewing. I will go back and find a way to handle this. Thank you.
I attached a new patch to prevent executing composeIds() twice in createExecution(). All of testcase could pass. If you have time, please have a look at it.
The key is we have to generate dbid, parent id, then we could save the execution. And the code for generating dbid is only exists in the save() method. setParent() mehod is only exists in the addExecution() method.
So this time, I execution setParent() by hand before save(). I think this could be solve this problem.
Looks good to me.
Done, checked in r6414.