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 Tue, 01 Dec 2009 22:01:41 GMT
On 02/12/2009, at 5:09 AM, Weddle, Anthony wrote:

> The confusing thing, in this exchange is why Lachlan would be concerned about an object
which, on the face of it, should never have been constructed (since it was created and then
deleted, before it was ever persisted), or why he would want to create objects to replace
those that had been deleted.

Perhaps a real example will help clear up any confusion here. This is for ROP, btw.

So we have an interface which presents to the user a Payslip with a series of (i.e., toMany)
paylines. Depending on the information supplied per-line the line will either be discarded
or included. Unlike the web (at least web 1.0) this state can toggle frequently.

Now, without creating objects in the first place you both have nothing to validate (validateForSave)
nor can you roll-back changes (should this have been a previously persisted object). In either
case, the controller/ui doesn't care...

> From the program's point of view, it's clear that TRANSIENT can be treated exactly the
same as DELETED, since they both mean that some persistable object previously created in the
program has subsequently been deleted by the program.

My point (and clarifying question, however) is that if TRANSIENT does not always mean that
... and it's possible for objects to be transient in other ways then that's not good enough.
It'll do for now - but I'd like to put code in the entity that works in all circumstances
and not just for this particular case.

> From the database's point of view, the states can't be treated the same way; the DELETED
object has to be deleted from the database, the TRANSIENT object was never in the database
and can be ignored.

That's the easy part, sure. But from user-code's point of view, we don't care about the database.
It's an abstraction. :-) Thinking in terms of the database when using an orm ain't best practice
(of course you need to at times). Think in terms of objects.

with regards,

Lachlan Deck

View raw message