Re: Making sense of callbacks

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Sep 23 2009 - 08:32:43 EDT

  • Next message: Andrus Adamchik: "Re: Making sense of callbacks"

    Having run into some issues with callbacks myself and generally
    gaining better insight into callbacks patterns, I second what Ari has
    suggested two years ago in the message below. Namely I suggest the
    following changes:

    1. call pre/postUpdate for new objects. So new objects will have pre/
    postPersist as well as pre/postUpdate callbacks. Of course the main
    motivation is that preUpdate is called before save, not after context
    insert, so all the relationships are in place.

    2. stop calling pre/postUpdate for removed objects. This is causing
    grief when we need to access relationships of a deleted object.

    Both changes are actually still compatible with JPA spec, due to the
    vagueness mentioned below. This may affect the callbacks currently in
    use by 3.0 applications, so this is our last chance to slip it in
    before the beta, and also we need to make it clear what upgrade steps
    need to be taken by the current 3.0 users.

    If there's no objections, I will work on such change.

    (Also not sure how this affects ROP yet?)

    Andrus

    On Nov 29, 2007, at 10:56 AM, Aristedes Maniatis wrote:
    > On 29/11/2007, at 12:28 PM, Aristedes Maniatis wrote:
    >
    >> Summary
    >> -------
    >>
    >> * prePersist() is only useful as a place to set object attributes
    >> (such as creationDate) since you cannot follow relations reliably
    >> in a ROP environment.
    >>
    >> * postUpdate() and postPersist() are useful for changes which do
    >> not need to be committed atomically with the original commit. So
    >> good for creating log records, but not ideal for updating
    >> invoiceOwing.
    >>
    >> * postPersist() is badly named. It is really postInsert()
    >>
    >> * we need preInsert()
    >
    >
    > With some further reading of the JPA specification I have come to
    > the following conclusions:
    >
    > * the JPA was written by lawyers who get paid by the word
    >
    > * postPersist() is defined in the JPA to occur after a NEW record is
    > written to the database. Which is how Cayenne works.
    >
    > * pre/postUpdate(): the JPA specification is very very unclear, but
    > it looks like maybe it might apply for both new and existing
    > records. But then postUpdate() overlaps postPersist() which is a bit
    > pointless.
    >
    > * if preUpdate() is just for existing records we still need a
    > preInsert().
    >
    >
    > So, even though we have to follow the poorly named callbacks in JPA,
    > an extra callback would fill a useful hole.
    >
    >
    > Ari
    >
    >
    > -------------------------->
    > ish
    > http://www.ish.com.au
    > Level 1, 30 Wilson Street Newtown 2042 Australia
    > phone +61 2 9550 5001 fax +61 2 9550 4001
    > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Wed Sep 23 2009 - 08:33:39 EDT