Re: addToManyTarget() changes PersistenceState.COMMITTED to PersistenceState.MODIFIED

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Wed Sep 24 2003 - 21:14:12 EDT

  • Next message: JR Ruggentaler: "Database Diagram view"

    On Wednesday, September 24, 2003, at 08:47 PM, Mike Kienenberger wrote:
    >> For one thing (unrelated to the present discussion) class generation
    >> shouldn't produce any setters, only getters. This will explicitly show
    >> the user that the object is not for modification.
    >
    > My own class generation templates already only generate getters. It'd
    > be
    > pretty easy for me to produce a patch for this against the standard
    > templates if you'd like. I warn you that my read-only objects can
    > still
    > have one-to-many relationships, though :)

    In the light of this discussion this is totally acceptable, so please
    send a patch.

    >> As for 1..n relationships when to-one is read-only....Maybe instead
    >> of
    >> fast failure in commit, first check for db-level modifications, and
    >> ignore purely object-level changes, like to-many array
    >> modification....
    >> So the object will still be MODIFIED until commit is executed. After
    >> that it will become COMMITTED even if nothing was saved for this
    >> object.
    >
    > That works for me. I started my research by checking to see if there
    > was a
    > read-only dbEntity flag in addition to the objEntity read-only flag,
    > but I
    > didn't see one. I knew that there must be reason why the code was the
    > way
    > it was (and correctly suspected the reason), but I still need working
    > code
    > :) As things stand, it seems to me that the PersistentState variable
    > implements db-level changes, not object-level changes. Maybe there
    > should
    > be another such variable rather than trying to overload it with two
    > meanings?

    I don't see a problem with current implementation... Actually I feel
    like PersistentState is more about object graph than database changes.
    "commit" reconciles the two.

    > Is there anything I can do to help this process along? I hate having
    > to run
    > a hacked version of Cayenne.

    If you want to play with ContextCommit class to defer "read-only"
    exception for MODIFIED objects till the object is cleared
    (ContextCommit, line 420), the patch is more than welcomed.

    Andrus



    This archive was generated by hypermail 2.0.0 : Wed Sep 24 2003 - 21:14:03 EDT