Another potential gotcha with detachable models is that they can make versioning/optimistic locking a bit more difficult to use. Unless you cache the base version of your entity in the detachable model and do your own version checking, the typical implementations that I have seen will happily reload and overwrite whatever version happens to be in the database at the time of a request. This means, for example, that the user might see a form that is initialized with version 1 of your object, and then update version 2 if somebody else comes along and makes changes before they submit, potentially wiping out the other user's changes.
Obviously, this only affects you if you are versioning your objects. It's just a nice tidbit to have in the knowledge base...and again, you can design your detachable models around it. You just end up with a little duplication of effort, as Hibernate/JPA/etc. already does this for you elsewhere.
Ayodeji Aladejebi wrote:
thanks eelco i get your point. deciding what to sacrifice in design whether memory or cpu/db traffic is always some challenge for most developers but if I dont want my DB crying then its probably time to buy more RAM
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
