On 02/12/2009, at 9:35 AM, Weddle, Anthony wrote:
> -----Original Message-----
> From: Lachlan Deck [mailto:lachlan.dec..mail.com]
>
>> 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...
>
> OK. So the main problem is roll-back.
It's 'a' feature. Not the main/only problem.
> Obviously, to validate an object, you need the object but there's no need to validate a deleted object,
Of course. It won't validate whilst transient, though validateForDelete is relevant otherwise.
> I would have thought (and, presumably, it wouldn't be deleted until analysed).
To provide immediate user feedback, validation is triggered after each event (for us).
> So what is the roll-back point? Is it the last persisted state of the objects?
Sure.
> If so, then you don't need to know the current state of the objects and can create whole new objects or read them from the database, as you did at the start of the processes.
That's not the problem I'm solving. But sure, if someone hits cancel then that will occur.
> If it is some intermediate state, that you need to roll back to, then you should store that state in the program, not the object context, as far as I can tell.
I've got it working using Cayenne as I believe it should (though still not 100% that it covers all transient possibilities). Intermixing non-object state and custom state wouldn't be preferable.
> The context is there because of Cayenne, not because of the logic in your program.
Well.... on this I'll admit that I come from EOF where this particular action/case didn't require as much, um, thinking :-) To put it another way, I understand your logic here I just don't completely agree with it :)
> Perhaps you can delay any deletion, in context terms, until you know what is ultimately going to be saved.
That's not practical. If a save action is triggered that needs further work to be done by the user (requiring a subsequent save) at which point are the deletions inserted? It doesn't work.
>>> 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.
>
> Ah, well, if you really do need to use context state for your code, then that would have to be the question to those that know: what situations can result in an object state of TRANSIENT? Maybe you can confidently assume that TRANSIENT is the same as DELETED, from the program's point of view. If not, then you'll have to avoid using the context for the purposes of your application's logic.
Certainly I'd have to handle it otherwise... which would be a shame for it diminishes the transparency of dealing with creating/deleting/updating objects no matter their destination.
>>> 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.
>
> Indeed. By the same token, it is perhaps unwise to use something (the object context) that exists purely because of the persistence framework, unless you are strictly coding persistence logic.
We are strictly coding persistence logic. Even sql has conditional statements that may or may not cause alterations to any rows... that's the key point that imho you're missing...
> If you ever change the persistence framework, it may be hard to untangle the old one from your code.
That's always going to be true I'm afraid.
Anyway, thanks for your input.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Tue Dec 01 2009 - 18:15:36 EST