On Jun 19, 2007, at 12:08 PM, carlos f wrote:
Norman Franke wrote:
In my case, my DAO has an
"assertUnchanged" method that throws an exception if the two objects
differ, e.g. my detached object and the one read from the database.
In this case, I tell the user that someone else changed their record
and their changes have been lost.
Why not rely on Hibernate's version support for detached objects and
versioning?
Several reasons.
1. As Michael noted, they aren't thread safe.
2. This really gets to a bigger issue, in that these objects aren't
valid outside of a session. Once the session closes, they are
technically invalid according to what I read in "Hibernate in
Action". This is because Hibernate may want to lazy fetch things,
e.g. relationships. It leave us with a proxy object or somesuch,
which is likely larger than my object and not as serializable
friendly. My detached object is serialized into the client's web
page, so size matters.
3. I can't use versioning since I'm using a legacy schema without
support for versions.
Norman Franke wrote:
To persist a detached object, I call a clone() function on all of my
DB objects that converts it back to a normal POJO (from whatever
Hibernate does to it.)
Why clone the detached object graph? Why not have the DAO reattach
it to
the session and save it -- assuming it passes your version check?
I don't clone the graph, just the properties (i.e. not
relationships.) If I need the relationships, I do then reattach. This
clone is stored in the client page (or it could be stored in the
session, if desired. I store it in the client page to save memory.)
-Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
