cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <>
Subject Re: delete new --> transient?
Date Mon, 30 Nov 2009 22:40:52 GMT
On 28/11/2009, at 2:01 AM, Michael Gentry wrote:

> On Thu, Nov 26, 2009 at 12:52 PM, Lachlan Deck <> wrote:
>> On 27/11/2009, at 2:24 AM, Andrey Razumovsky wrote:
>>> Because for deleted objects DELETE query will be forced, and if you create
>>> (register), then delete (unregister) an object it looks like as if it was
>>> never registered in context.
>> This seems (to me, at least) to be implementation details of the framework that's
overly exposed to general users ('cause you have to know the implementation details in order
to make any use of those persistence states in any meaningful way.... e.g., what does transient
mean? Well it depends.... What does deleted mean? Again it depends on other conditions.).
Perhaps then PersistenceState should be private to the framework.
> Sometimes application code needs access to this and making it private
> wouldn't help that matter.

Sure - it can be convenient to have access to internals.

>> 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?

> So Cayenne is working properly in this
> regard.

I'm not suggesting it's not behaving as expected.

> If an object has never been persisted (does NOT exist in the
> DB), then it is marked as transient if you delete it.

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 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.
> By context I assume you mean data/object context.


> My previous comment
> still applies.  :-)  The DataContext needs to know what to do when you
> commitChanges().

Of course it does.

> 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

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. :-)

> Here is TRANSIENT:
>    /**
>     * Describes a state of an object not registered with
> DataContext/ObjectContext, and
>     * therefore having no persistence features.
>     */
>    public static final int TRANSIENT = 1;
> If you register an object with a DC and then delete it (without ever
> persisting it), then it becomes TRANSIENT.  If you register an object
> with a DC, commit it, then delete it, it becomes DELETED.  Keep in
> mind the DC exists to manage your objects for committing changes to
> the DB, not to track general Java usage (such as removing an object
> from a collection).

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

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

with regards,

Lachlan Deck

View raw message