Re: delete new --> transient?

From: Lachlan Deck (lachlan.dec..mail.com)
Date: Tue Dec 01 2009 - 17:01:41 EST

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

    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



    This archive was generated by hypermail 2.0.0 : Tue Dec 01 2009 - 17:02:21 EST