cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Order of operations?
Date Fri, 01 Jul 2016 00:43:21 GMT
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.


> On Jun 22, 2016, at 9:32 PM, Michael Gentry <> 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 <>
> 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]
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message