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 01:01:27 GMT
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 :)


> On Jun 30, 2016, at 8:43 PM, Andrus Adamchik <> 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 <> 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