It may be time to revisit current AshwoodEntitySorter and start building/sorting DB operations based on the object graph change log. Relationships between objects participating in a given transaction will likely provide us with a better insight about sorting then analyzing the underlying entities by themselves (something that we do now). The we can execute a mix of INSERT/UPDATE/DELETE in an order defined dynamically based on a commit set at hand.
Perhaps it will also help us in resolving dependency cycles, where there's no single valid operation order for simple operations (e.g. creating both department and its manager who is also a department employee). This can be solved by running an INSERT with null FK on one side of the cycle followed by UPDATE with the right PK. Also current AshwoodEntitySorter approach is geared towards merging all semantically identical operations in batched PreparedStatements, thus improving performance of large commits. If we are to do something new, we'll need to take this into account. So there are tradeoffs and challenges and this won't be an easy task. But if anyone feels like applying their graph theory knowledge to a non-trivial problem, please speak up :) Andrus > On Jun 30, 2016, at 8:43 PM, Andrus Adamchik <and...@objectstyle.org> wrote: > > There are cases when INSERT -> UPDATE -> DELETE is the only order that would > satisfy the constraints. Such as when UPDATE nullifies FKs to the record that > is later deleted. So this was a conscious decision. Too simplistic of course, > as we've seen here. So a smarter algorithm is in order. But just reversing it > to DELETE -> UPDATE -> INSERT (or picking any other fixed order for that > matter) is going to break apps that work currently. > > Andrus > > >> On Jun 22, 2016, at 9:32 PM, Michael Gentry <blackn...@gmail.com> wrote: >> >> I believe I inquired about the ordering years ago and I think Andrus gave a >> reason why, but it escapes me at the moment. Perhaps he will remember and >> chime in here. >> >> mrg >> >> >> On Wed, Jun 22, 2016 at 6:58 PM, Aristedes Maniatis <a...@maniatis.org> >> wrote: >> >>> On 23/06/2016 5:25am, Lon Varscsak wrote: >>>> Okay, I’ve found where it’s at (DataDomainFlushAction.preprocess). I >>> don’t >>>> see an easy way to override this, without just forking (which is totally >>>> doable). Does anyone know why the default order of operations is INSERT >>> -> >>>> UPDATE -> DELETE? Because if there’s no specific reason, it seems like >>> we >>>> could change this to support DBs that don’t have deferred constraints. >>> (or >>>> provide a hook to reorder these) >>> >>> >>> That's a pretty old piece of code, probably before my time. The history is >>> unfortunately broken by a move back in 2013 [1] but it would be interesting >>> to go back to the origins of that file and see if any commit message sheds >>> light on why that ordering was chosen. It does seem an odd choice, but >>> perhaps there was a reason. >>> >>> Before you fork Cayenne let's see if we can improve this behaviour for the >>> entire community. >>> >>> >>> [1] >>> https://github.com/apache/cayenne/commits/b0631deb251f036840d1ca3aee6d4ae50f2441bf/cayenne-server/src/main/java/org/apache/cayenne/access/DataDomainFlushAction.java >>> >>> -- >>> --------------------------> >>> Aristedes Maniatis >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>> >
