Re: delete new --> transient?

From: Michael Gentry (mgentr..asslight.net)
Date: Tue Dec 01 2009 - 09:54:04 EST

  • Next message: Weddle, Anthony: "RE: delete new --> transient?"

    On Mon, Nov 30, 2009 at 5:40 PM, Lachlan Deck <lachlan.dec..mail.com> wrote:
    > On 28/11/2009, at 2:01 AM, Michael Gentry wrote:
    >> On Thu, Nov 26, 2009 at 12:52 PM, Lachlan Deck <lachlan.dec..mail.com> wrote:
    >>> But this still means that there's no 'general purpose' method that I'm aware of (e.g., in Cayenne 'the new static helper' ... ah, see, if you'd called it CayenneUtils or PersistentUtils there'd be no need for further clarification of what Cayenne refers to via email ;-)  which answers the basic question: 'is this object marked for deletion (regardless of whether it was previously persisted)?'
    >>
    >> Well, an object should only be marked for deletion if it needs to be
    >> deleted (it exists in the DB).
    >
    > This all depends on what 'deleted' means. If deleted were strictly for persisted objects as you suggest then why is deleteObject the method used to make transient those objects for which the action of deleting does not apply?

    The DataContext doesn't require the user to figure out if an object
    has been persisted before they call deleteObject() on it. Nor does
    the DataContext throw an exception if they call deleteObject() on a
    NEW object. The user clearly specified they no longer wanted the
    object to be stored by calling deleteObject() so the DataContext marks
    it as TRANSIENT if it has never been persisted or DELETED if it has
    been persisted. The commitChanges() will ignore the TRANSIENT objects
    in the DataContext.

    > The problem is that you cannot tell the difference between deleted transients and non-deleted transients by looking at its state. Is there something in the framework that tells me that an object was previously added to the context but was afterwards 'deleted' from it and is now marked as transient?

    I'm not exactly sure why you care if the TRANSIENT object had
    deleteObject() called on it or not. In general practice, though, the
    object will not be TRANSIENT *unless* you call deleteObject() on it
    and it is a brand new object. One typically does not call
    setPersistenceState() on objects. And one typically creates the
    object inside the DataContext (calling newObject()), which gives it a
    NEW state initially. If it has a persistence state of DELETED, you
    know it was previously persisted.

    >>> I simply want to know if an object is marked for deletion within the context. It should be simple like the question itself. :)    And to answer the question, because I need to know at a later point whether to replace the object with a new one.

    An object is marked for deletion, from the physical database, if the
    persistence state is DELETED.

    >> If an object's persistence state is set to DELETED,
    >> then the DC knows it needs to issue a DELETE to the DB on
    >> commitChanges()
    >
    > Are you saying that it has no knowledge otherwise as to whether the object was previously persisted?
    >
    > It could also 'know' that if an object's persistence state is set to deleted and the object was not previously persisted then it issues no sql. :-)

    The persistence state variable is used to identify this information.
    TRANSIENT = not persisted (or persistable).

    > As I understand it, an OC exists to abstract parent object stores from the user.. where that parent object store may or may not necessarily be a database. But this is all besides the point.

    The ObjectContext/DataContext does more than abstract the backing
    store. It provides a workspace or sandbox for changes to be made and
    then manages those changes within a transaction. If you throw away
    the context, no changes are done. To me it is more like checking out
    code from a repository (such as Subversion) into a workarea. You can
    checkout as many workareas (or contexts -- one or more for each user)
    as you want and make changes in them, but unless you commit them, the
    repository (or database) doesn't get updated and no one else will see
    those changes.

    > I'm just asking the question as to whether cayenne provides the information I'm after.

    I think Cayenne, especially in practical terms, tells you what you want.

    Hope that helps somewhat ...

    mrg



    This archive was generated by hypermail 2.0.0 : Tue Dec 01 2009 - 09:55:05 EST