-----Original Message----- From: Lachlan Deck [mailto:[email protected]]
> 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. Obviously, to validate an object, you need the object but there's no need to validate a deleted object, I would have thought (and, presumably, it wouldn't be deleted until analysed). So what is the roll-back point? Is it the last persisted state of the objects? 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. 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. The context is there because of Cayenne, not because of the logic in your program. Perhaps you can delay any deletion, in context terms, until you know what is ultimately going to be saved. >> 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. >> 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. If you ever change the persistence framework, it may be hard to untangle the old one from your code. Tony NOTICE - This message and any attached files may contain information that is confidential, legally privileged or proprietary. It is intended only for use by the intended recipient. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error. Any dissemination, copying, use or re-transmission of this message or attachment, or the disclosure of any information therein, is strictly forbidden. BlueScope Steel Limited does not represent or guarantee that this message or attachment is free of errors, virus or interference. If you have received this message in error please notify the sender immediately and delete the message. Any views expressed in this email are not necessarily the views of BlueScope Steel Limited.
