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 >>
