cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <blackn...@gmail.com>
Subject Re: Order of operations?
Date Fri, 01 Jul 2016 13:17:50 GMT
I looked at AshwoodEntitySorter a few years ago and also concluded it would
be non-trivial and likely would be more than just the graph library that
needed to be changed, such as extra logic to handle dependency cycles.

On Thu, Jun 30, 2016 at 9:01 PM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

> 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 <andrus@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 <blacknext@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 <ari@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
> >>>
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message