Jeromy Evans wrote:
Let me re-articulate my interpretation of what you've done:
You load an entity E with say 4 properties (a, b, c, and d) from
persistence and render a view based on it. The persistence session is
closed.
In a new thread, the user submits an update that affects only two
properties of the entity (E.a and E.b).
Your S2 action sets the E.a and E.b properties to their new values
directly. Consequently, the c and d properties the new E instance are
null.
A new persistence session is started.
You attempt to reattach/merge E back into persistence but the c and d
properties are persisted as null instead of their original values.
Jeromy, that's exactly what I need to know.
This is a classic CRUD use-case. As you have chosen to allow your
persistent entity to be modified within your action, your action needs
to implement Preparable, or use the PrepareParamsPrepare stack so you
can load E into a new persistence session prior to S2 applying the
updates to it.
You need to follow this approach:
You load an entity E with say 4 properties (a, b, c, and d) from
persistence and render a view based on it. The persistence session is
closed.
In a new thread, the user submits an update that affects only two of
the entity (E.a and E.b).
A new persistence session is started and E is reloaded from
persistence (Preparable) Your S2 action sets the E.a and E.b
properties to the new values. The c and d properties remain at their
their original values.
You commit E back into to persistence.
Now would also be a good time to understand Hibernate's revision
control features.
And definitely a great time to know how Preparable is really used.
By the way, hibernate session is not closed.
An alternative approach is that you don't allow persistent entities to
be modified within your actions whatsoever and all updates are applied
behind a service layer that performs reattachment and updates.
How do I do this (reattachment and updates)? Assuming I have a very big
and complex entities.
The most appropriate approach depends mainly on the complexity of your
entities and the separation of concerns you require.
OK, that's what I have in my business layer. Tere's a facade for my
business layer. The actions can obtain a reference to this facade
through the session by implemeting SessionAware.
I really appreciate your help.
Mansour wrote:
Hello every one:
This question may seem of topic. The reason I am asking this here is
because I am sure some one faced this problem when dealing with
struts and can provide an advice.
I have many objects that are mapped using hibernate to a DB. I need
to update one of these objects (lets call it Parent). But this object
contains many fields that I don't want to change. So the view here
can display and modify the fields I need to change. Now, when I pass
this object back, it's not a persistent object, and making it
persistent will conflict with the existing one. If I deattach the
original then I will lose the original values of the fields.
How can I get around this ? If some one have done this before, please
let me know.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
