On Tue, 2003-01-07 at 09:48, Andrus Adamchik wrote:
> Do you think this is something that we could put online? With the last
> release I started a small developer guide as a part of xdocs. We may create
> an "algorithms" chapter in it.
Hmmm, this looks best, with (as Holger suggested), a note in the actual
class pointing to the full explanation. That'll help the separation of
implementation comments from abstract algorithm notes.
> Also I wonder if this may fit into Andriy's graph library that Cayenne will
> eventually import? Just an idea.
Very probably. I had to rearrange the order of updates/inserts/deletes
in DataContext.commitChanges [1], and it seems likely that the whole
query order thing can probably be reduced to graph theory
manipulations. But I lack the mathematical skills to get my head around
that from scratch. Once Andriy's stuff has been integrated, I think
someone who knows their stuff could probably redo a lot of ordering code
(commitChanges particularly).
Craig
[1] Nullify delete rules mean that updating fk's to be null needs to
happen before the child record is deleted, to avoid running into
integrity constraints, plus flattened inserts/deletes need to be split
up, deletes done first (well, after updates), inserts done after
everything else. The unit tests all run, but I'm rather nervous about
this so I'll sit on it for a day or two, write some more tests etc,
before committing.
>
> Andrus
>
>
>
> Craig Miskell writes:
>
> > Hi all,
> > I've finally worked around the madness associated with delete rules
> > (more tests needed... it still makes me nervous), but in the process
> > have some mildly complex alogorithms (they make more sense as you study
> > them, but initially they are hard to grok). Where is the best place for
> > some largish scale algorithm notes (pseudo code probably, plus
> > discussion) on WHY it all works. These are definitely a good idea, for
> > aiding bug fixing and refactoring (or rewriting), providing a baseline
> > for what should be happening. If the theory is wrong, then it can be
> > modified along with the code, or if the code doesn't match it can be
> > fixed (rather than wondering if a given concept is deliberate or not)
> >
> > A big comment block before the method? That's my preference, but then
> > the code has a big chunk of comment in it (which can look out of place
> > sometimes). Somewhere else?
> >
> >
> > Craig
> >
> >
>
This archive was generated by hypermail 2.0.0 : Mon Jan 06 2003 - 16:16:20 EST