Re: Making sense of callbacks

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Sun Sep 27 2009 - 21:08:05 EDT

  • Next message: Aristedes Maniatis: "Re: Making sense of callbacks"

    On 28/09/2009, at 12:13 AM, Andrus Adamchik wrote:

    > I am +1 on:
    >
    > * Radical renaming if that helps us with consistency.
    > * The observation that pre/postCommit for NEW and MODIFIED objects
    > are often identical (in my use cases they are always identical).
    > Wonder in what case it is important to distinguish in postCommit
    > whether the object was new or modified before commit?

    I'm hoping these combined callbacks are not replacing individual ones.

    > <..>
    > Conclusion:
    >
    > So mixing Ari's idea with my points above, we have something like
    > that:
    >
    > * postLoad
    >
    > * postAdd ("post" as it is invoked after object is added to the
    > context)
    > * preDelete ("pre" as it is invoked before delete rules are
    > processed and before the object state is changed)
    If you're going that way you'd need a preUpdate to match (wouldn't
    you?) to keep it balanced.

    > * preCommit
    > * preCommitDeleted
    > * postCommit
    > * postCommitDeleted
    >
    > ... or we can go completely the Cayenne way and change the callback
    > signatures to take an enum characterizing the event nature, or even
    > some sort of an event object.

    Not personally keen on if-else based lifecycle callbacks... but I
    suppose everyone's superclass can call the relevant signature.

    Just to review the thread.... I'm not sure such a drastic change is
    needed to make lifecycle callbacks complete/useful. There was one
    (maybe two) missing and some adjusted behaviour / clarification needed
    overall, no(?) rather than a complete change?

    i.e., it seems to me it's mostly good but with some gaps
    postLoad .. after fetch

    prePersist ... should be instead called (whether ROP or not) after
    validateForSave but before persisting a new object
    preUpdate ... as now, after validation and before persisting updates
    to an already persisted object
    preDelete ... again after validation but prior to deleting from the
    objectstore

    postPersist
    postUpdate
    postDelete .. all logically matching their pre counterparts.

    what's missing?
    postInsert .. called after an object is created and inserted into a
    context

    So from what I can see the only two changes required were 'postInsert'
    and adjusting the meaning of prePersist

    with regards, 

    --

    Lachlan Deck

    This archive was generated by hypermail 2.0.0 : Sun Sep 27 2009 - 21:08:26 EDT