You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Shawn Church <sh...@boxity.com> on 2005/02/22 19:22:18 UTC
Detached object management
I am moving forward with integrating Hibernate and Tapestry, and I have
now added Spring into the mix. I've eliminated lazy initialization
exceptions (so far), but I'm now trying to establish a set of best
practices for working with detached objects. Here's a simple
description of what I'm trying to do:
1. Load an object graph (ie - Cat, one-to-many with Kittens).
2. setCat(cat) abstract method
3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
4. <a jwcid="@DirectLink" listener="ognl:listeners.kittenSelectAction"
parameters="ognl:kitten">
5. In kittenSelectAction(), Kitten kitten = (Kitten) parameters[0];
6. setKitten(kitten) abstract method (same page as before)
7. Render page again, showing previous (persistent) kitten list (as
before), but now editing the selected kitten.
8. Input a new kitten property (ie - kitten.name)
9. Form submit handler validates everything and updates the edited kitten.
This last step is where I am unsure of the best method. My Hibernate
mappings are set to cascade save-update, and I would like to update the
Kitten (along with any other updates which may have been made to Cat)
with getCatService().save( getCat()).
Since the original kitten instance would have been serialized and
deserialized, I need to reassociate the detached Kitten with the Cat
object graph. It works fine to explicitly save the Kitten (ie -
getKittenService().save( getKitten()), but I have to be careful not to
save the Cat without first re-fetching the kitten list. This also
doesn't take full advantage of Hibernate's cascading update.
Is this the point of using Session.update() or Session.lock()? If so,
where is the best place (and time) to do this? I would rather keep this
out of the page controller if possible.
I also realize there are other/better ways of performing the above
sequence, but since this exploits Tapestry's capabilities I would like
to find a clean way of implementing this.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Detached object management
Posted by Henri Dupre <he...@gmail.com>.
On Tue, 22 Feb 2005 16:02:10 -0500, Ryan Owens <ry...@infoether.com> wrote:
> > I have Hibernate working fine with a couple of other Tapestry-based
> > apps, but I've had to cut a few corners (especially relating to lazy
> > initialization) for it to work reliably. I too avoided introducing
> > Spring for a long time, but on my current project I decided to bite the
> > bullet and give it a try. It took some fairly significant refactoring
> > (since I wanted to take advantage of Spring's dependency injection in
> > the process), but I'm pleased with it so far. Yes, I'm using
> > OpenSessionInViewFilter, but I've read on the Spring list that it is
> > not
> > necessarily the best solution.
> >
> > I hesitated to litter my page implementations with Session.updates,
> > since I was hoping to keep Hibernate out of the way at this level.
> > There may be a Spring solution as well, so I may pose this question to
> > the Spring forum. If I go this route, how will I know which objects to
> > reattach? Do you just call Session.update() for every possible
> > detached
> > object used by your page, or do you somehow detect which objects may be
> > detached?
>
> I haven't landed on a specific "best practice" here yet, but here is
> what I 'think' is true:
>
> -all hibernate sessions are closed after each request
> -therefore it can be assumed that all properties not explicitly loaded
> in pageBeginRender, persistent or otherwise have been detached.
> -any detached objects with collections you intend to access should be
> reattached (to avoid Lazy exceptions)
> -any detached objects which may be duplicated somewhere and may be
> persisted must be reattached
> -eg. you have a persistent list of kittens and deletedKitten property
> set by a listener. the deletedKitten object object exists in both
> properties.
> *I believe reattaching will avoid the 'duplicate object for
> id' problem as well as the 'lazy collection' problem.
>
I'm currently developing a website with Hibernate 3 + Spring + Tapestry.
> So... while it seems like you need to manage a lot of updates and
> whatnot, it seems that the 2 generalizations I have are:
>
> **reattach all persistent properties during pageBeginRender
> -since most all of my persistent properties involve this check:
> if (getPersistentKitten() == null) {
> setPersistentKitten(KittenDAO.load()); }
> -it's then pretty easy to just universally make it:
> if (getPersistentKitten() == null) {
> setPersistentKitten(DAO.load()); }
> else{ /reattach
> DAO.update(getPersistentKitten(); )
>
> **reattach objects you are saving/updating or deleting
> - since I already have a method with code to delete the kitten, it's
> fairly easy to just add the session.update call there.
> - assuming this approach works universally, you could even extract
> this to a custom HibernateTapestryUtil
>
> so I'm adding session.update calls for persistent properties on each
> page that has them, and I'm reattaching objects just before I
> save/update/delete them.
> My testing is by no means exhaustive, nor are my use cases, but this is
> where my thinking is at currently.
>
> Hope that helps, I'd love to get your take on these ideas. I'm sure
> there are some gaping holes to be pointed out.
>
> yours,
>
> Ryan Owens
>
>
> > Thanks,
> > Shawn
> >
> >
> > Quoting Ryan Owens <ry...@infoether.com>:
> >
> >> I just went through the Hibernate/Tapestry integration excercise and
> >>
> >> there are quite a few gotchas.
> >> I opted to not use Spring since it seems like a lot more than I need
> >>
> >> and I really wanted to be Tapestry centric and use HiveMind
> >> eventually.
> >>
> >> Our situations are not identical, but the approach I took was to to
> >> call Session.update(kitten) during the pageBeginRender method.
> >> I am currently using this approach on any persistent properties and
> >> any
> >> other properties that need to be reattached.
> >> The gotcha I ran into has to do with the pageBeginRender being called
> >>
> >> on render and rewind, so I added a check to only attach on the
> >> initiial
> >> request, not the rewind. I may have that mixed up at the moment
> >> though,
> >> so don't take my word for it.
> >>
> >> Sorry I'm not more definitive but I am also trying to establish a
> >> Hibernate/Tapestry best practices, just not with Spring.
> >>
> >> Using Spring you are probably using the OpenSessionInView filter,
> >> whereas I opted to handle my hibernate transactions and sessions in a
> >>
> >> custom Engine class in the setupForRequest and cleanupAfterRequest
> >> methods as someone recommended on hibernate.org somewhere. I had to
> >> use
> >> the reattach in pageBeginRender technique to avoid lazy collection
> >> exceptions, as well as to get cascading to work. Since my
> >> transactions
> >> always begin and end in a single request then each page, including
> >> re-displayed validation error pages need to reattach objects they are
> >>
> >> going to work with. I'm not sure how that translates to Spring
> >> though.
> >>
> >> Hope that helps. I'd be glad to post my current draft of "best
> >> practices" if you think it would be helpful.
> >>
> >> -Ryan Owens
> >>
> >>
> >> On Feb 22, 2005, at 1:22 PM, Shawn Church wrote:
> >>
> >>> I am moving forward with integrating Hibernate and Tapestry, and I
> >> have
> >>> now added Spring into the mix. I've eliminated lazy
> >> initialization
> >>> exceptions (so far), but I'm now trying to establish a set of best
> >>> practices for working with detached objects. Here's a simple
> >>> description of what I'm trying to do:
> >>>
> >>> 1. Load an object graph (ie - Cat, one-to-many with Kittens).
> >>> 2. setCat(cat) abstract method
> >>> 3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
> >>> 4. <a jwcid="@DirectLink"
> >> listener="ognl:listeners.kittenSelectAction"
> >>> parameters="ognl:kitten">
> >>> 5. In kittenSelectAction(), Kitten kitten = (Kitten)
> >> parameters[0];
> >>> 6. setKitten(kitten) abstract method (same page as before)
> >>> 7. Render page again, showing previous (persistent) kitten list
> >> (as
> >>> before), but now editing the selected kitten.
> >>> 8. Input a new kitten property (ie - kitten.name)
> >>> 9. Form submit handler validates everything and updates the edited
> >>
> >>> kitten.
> >>>
> >>> This last step is where I am unsure of the best method. My
> >> Hibernate
> >>> mappings are set to cascade save-update, and I would like to update
> >> the
> >>> Kitten (along with any other updates which may have been made to
> >> Cat)
> >>> with getCatService().save( getCat()).
> >>>
> >>> Since the original kitten instance would have been serialized and
> >>> deserialized, I need to reassociate the detached Kitten with the
> >> Cat
> >>> object graph. It works fine to explicitly save the Kitten (ie -
> >>> getKittenService().save( getKitten()), but I have to be careful not
> >> to
> >>> save the Cat without first re-fetching the kitten list. This also
> >>> doesn't take full advantage of Hibernate's cascading update.
> >>>
> >>> Is this the point of using Session.update() or Session.lock()? If
> >> so,
> >>> where is the best place (and time) to do this? I would rather keep
> >>
> >>> this
> >>> out of the page controller if possible.
> >>>
> >>> I also realize there are other/better ways of performing the above
> >>> sequence, but since this exploits Tapestry's capabilities I would
> >> like
> >>> to find a clean way of implementing this.
> >>>
> >>> Thanks
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >> tapestry-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> tapestry-user-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Detached object management
Posted by Ryan Owens <ry...@infoether.com>.
> I have Hibernate working fine with a couple of other Tapestry-based
> apps, but I've had to cut a few corners (especially relating to lazy
> initialization) for it to work reliably. I too avoided introducing
> Spring for a long time, but on my current project I decided to bite the
> bullet and give it a try. It took some fairly significant refactoring
> (since I wanted to take advantage of Spring's dependency injection in
> the process), but I'm pleased with it so far. Yes, I'm using
> OpenSessionInViewFilter, but I've read on the Spring list that it is
> not
> necessarily the best solution.
>
> I hesitated to litter my page implementations with Session.updates,
> since I was hoping to keep Hibernate out of the way at this level.
> There may be a Spring solution as well, so I may pose this question to
> the Spring forum. If I go this route, how will I know which objects to
> reattach? Do you just call Session.update() for every possible
> detached
> object used by your page, or do you somehow detect which objects may be
> detached?
I haven't landed on a specific "best practice" here yet, but here is
what I 'think' is true:
-all hibernate sessions are closed after each request
-therefore it can be assumed that all properties not explicitly loaded
in pageBeginRender, persistent or otherwise have been detached.
-any detached objects with collections you intend to access should be
reattached (to avoid Lazy exceptions)
-any detached objects which may be duplicated somewhere and may be
persisted must be reattached
-eg. you have a persistent list of kittens and deletedKitten property
set by a listener. the deletedKitten object object exists in both
properties.
*I believe reattaching will avoid the 'duplicate object for
id' problem as well as the 'lazy collection' problem.
So... while it seems like you need to manage a lot of updates and
whatnot, it seems that the 2 generalizations I have are:
**reattach all persistent properties during pageBeginRender
-since most all of my persistent properties involve this check:
if (getPersistentKitten() == null) {
setPersistentKitten(KittenDAO.load()); }
-it's then pretty easy to just universally make it:
if (getPersistentKitten() == null) {
setPersistentKitten(DAO.load()); }
else{ /reattach
DAO.update(getPersistentKitten(); )
**reattach objects you are saving/updating or deleting
- since I already have a method with code to delete the kitten, it's
fairly easy to just add the session.update call there.
- assuming this approach works universally, you could even extract
this to a custom HibernateTapestryUtil
so I'm adding session.update calls for persistent properties on each
page that has them, and I'm reattaching objects just before I
save/update/delete them.
My testing is by no means exhaustive, nor are my use cases, but this is
where my thinking is at currently.
Hope that helps, I'd love to get your take on these ideas. I'm sure
there are some gaping holes to be pointed out.
yours,
Ryan Owens
> Thanks,
> Shawn
>
>
> Quoting Ryan Owens <ry...@infoether.com>:
>
>> I just went through the Hibernate/Tapestry integration excercise and
>>
>> there are quite a few gotchas.
>> I opted to not use Spring since it seems like a lot more than I need
>>
>> and I really wanted to be Tapestry centric and use HiveMind
>> eventually.
>>
>> Our situations are not identical, but the approach I took was to to
>> call Session.update(kitten) during the pageBeginRender method.
>> I am currently using this approach on any persistent properties and
>> any
>> other properties that need to be reattached.
>> The gotcha I ran into has to do with the pageBeginRender being called
>>
>> on render and rewind, so I added a check to only attach on the
>> initiial
>> request, not the rewind. I may have that mixed up at the moment
>> though,
>> so don't take my word for it.
>>
>> Sorry I'm not more definitive but I am also trying to establish a
>> Hibernate/Tapestry best practices, just not with Spring.
>>
>> Using Spring you are probably using the OpenSessionInView filter,
>> whereas I opted to handle my hibernate transactions and sessions in a
>>
>> custom Engine class in the setupForRequest and cleanupAfterRequest
>> methods as someone recommended on hibernate.org somewhere. I had to
>> use
>> the reattach in pageBeginRender technique to avoid lazy collection
>> exceptions, as well as to get cascading to work. Since my
>> transactions
>> always begin and end in a single request then each page, including
>> re-displayed validation error pages need to reattach objects they are
>>
>> going to work with. I'm not sure how that translates to Spring
>> though.
>>
>> Hope that helps. I'd be glad to post my current draft of "best
>> practices" if you think it would be helpful.
>>
>> -Ryan Owens
>>
>>
>> On Feb 22, 2005, at 1:22 PM, Shawn Church wrote:
>>
>>> I am moving forward with integrating Hibernate and Tapestry, and I
>> have
>>> now added Spring into the mix. I've eliminated lazy
>> initialization
>>> exceptions (so far), but I'm now trying to establish a set of best
>>> practices for working with detached objects. Here's a simple
>>> description of what I'm trying to do:
>>>
>>> 1. Load an object graph (ie - Cat, one-to-many with Kittens).
>>> 2. setCat(cat) abstract method
>>> 3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
>>> 4. <a jwcid="@DirectLink"
>> listener="ognl:listeners.kittenSelectAction"
>>> parameters="ognl:kitten">
>>> 5. In kittenSelectAction(), Kitten kitten = (Kitten)
>> parameters[0];
>>> 6. setKitten(kitten) abstract method (same page as before)
>>> 7. Render page again, showing previous (persistent) kitten list
>> (as
>>> before), but now editing the selected kitten.
>>> 8. Input a new kitten property (ie - kitten.name)
>>> 9. Form submit handler validates everything and updates the edited
>>
>>> kitten.
>>>
>>> This last step is where I am unsure of the best method. My
>> Hibernate
>>> mappings are set to cascade save-update, and I would like to update
>> the
>>> Kitten (along with any other updates which may have been made to
>> Cat)
>>> with getCatService().save( getCat()).
>>>
>>> Since the original kitten instance would have been serialized and
>>> deserialized, I need to reassociate the detached Kitten with the
>> Cat
>>> object graph. It works fine to explicitly save the Kitten (ie -
>>> getKittenService().save( getKitten()), but I have to be careful not
>> to
>>> save the Cat without first re-fetching the kitten list. This also
>>> doesn't take full advantage of Hibernate's cascading update.
>>>
>>> Is this the point of using Session.update() or Session.lock()? If
>> so,
>>> where is the best place (and time) to do this? I would rather keep
>>
>>> this
>>> out of the page controller if possible.
>>>
>>> I also realize there are other/better ways of performing the above
>>> sequence, but since this exploits Tapestry's capabilities I would
>> like
>>> to find a clean way of implementing this.
>>>
>>> Thanks
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>> tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> tapestry-user-help@jakarta.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Detached object management
Posted by Shawn Church <sh...@boxity.com>.
I have Hibernate working fine with a couple of other Tapestry-based
apps, but I've had to cut a few corners (especially relating to lazy
initialization) for it to work reliably. I too avoided introducing
Spring for a long time, but on my current project I decided to bite the
bullet and give it a try. It took some fairly significant refactoring
(since I wanted to take advantage of Spring's dependency injection in
the process), but I'm pleased with it so far. Yes, I'm using
OpenSessionInViewFilter, but I've read on the Spring list that it is not
necessarily the best solution.
I hesitated to litter my page implementations with Session.updates,
since I was hoping to keep Hibernate out of the way at this level.
There may be a Spring solution as well, so I may pose this question to
the Spring forum. If I go this route, how will I know which objects to
reattach? Do you just call Session.update() for every possible detached
object used by your page, or do you somehow detect which objects may be
detached?
Thanks,
Shawn
Quoting Ryan Owens <ry...@infoether.com>:
> I just went through the Hibernate/Tapestry integration excercise and
>
> there are quite a few gotchas.
> I opted to not use Spring since it seems like a lot more than I need
>
> and I really wanted to be Tapestry centric and use HiveMind
> eventually.
>
> Our situations are not identical, but the approach I took was to to
> call Session.update(kitten) during the pageBeginRender method.
> I am currently using this approach on any persistent properties and
> any
> other properties that need to be reattached.
> The gotcha I ran into has to do with the pageBeginRender being called
>
> on render and rewind, so I added a check to only attach on the
> initiial
> request, not the rewind. I may have that mixed up at the moment
> though,
> so don't take my word for it.
>
> Sorry I'm not more definitive but I am also trying to establish a
> Hibernate/Tapestry best practices, just not with Spring.
>
> Using Spring you are probably using the OpenSessionInView filter,
> whereas I opted to handle my hibernate transactions and sessions in a
>
> custom Engine class in the setupForRequest and cleanupAfterRequest
> methods as someone recommended on hibernate.org somewhere. I had to
> use
> the reattach in pageBeginRender technique to avoid lazy collection
> exceptions, as well as to get cascading to work. Since my
> transactions
> always begin and end in a single request then each page, including
> re-displayed validation error pages need to reattach objects they are
>
> going to work with. I'm not sure how that translates to Spring
> though.
>
> Hope that helps. I'd be glad to post my current draft of "best
> practices" if you think it would be helpful.
>
> -Ryan Owens
>
>
> On Feb 22, 2005, at 1:22 PM, Shawn Church wrote:
>
> > I am moving forward with integrating Hibernate and Tapestry, and I
> have
> > now added Spring into the mix. I've eliminated lazy
> initialization
> > exceptions (so far), but I'm now trying to establish a set of best
> > practices for working with detached objects. Here's a simple
> > description of what I'm trying to do:
> >
> > 1. Load an object graph (ie - Cat, one-to-many with Kittens).
> > 2. setCat(cat) abstract method
> > 3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
> > 4. <a jwcid="@DirectLink"
> listener="ognl:listeners.kittenSelectAction"
> > parameters="ognl:kitten">
> > 5. In kittenSelectAction(), Kitten kitten = (Kitten)
> parameters[0];
> > 6. setKitten(kitten) abstract method (same page as before)
> > 7. Render page again, showing previous (persistent) kitten list
> (as
> > before), but now editing the selected kitten.
> > 8. Input a new kitten property (ie - kitten.name)
> > 9. Form submit handler validates everything and updates the edited
>
> > kitten.
> >
> > This last step is where I am unsure of the best method. My
> Hibernate
> > mappings are set to cascade save-update, and I would like to update
> the
> > Kitten (along with any other updates which may have been made to
> Cat)
> > with getCatService().save( getCat()).
> >
> > Since the original kitten instance would have been serialized and
> > deserialized, I need to reassociate the detached Kitten with the
> Cat
> > object graph. It works fine to explicitly save the Kitten (ie -
> > getKittenService().save( getKitten()), but I have to be careful not
> to
> > save the Cat without first re-fetching the kitten list. This also
> > doesn't take full advantage of Hibernate's cascading update.
> >
> > Is this the point of using Session.update() or Session.lock()? If
> so,
> > where is the best place (and time) to do this? I would rather keep
>
> > this
> > out of the page controller if possible.
> >
> > I also realize there are other/better ways of performing the above
> > sequence, but since this exploits Tapestry's capabilities I would
> like
> > to find a clean way of implementing this.
> >
> > Thanks
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Detached object management
Posted by Ryan Owens <ry...@infoether.com>.
I just went through the Hibernate/Tapestry integration excercise and
there are quite a few gotchas.
I opted to not use Spring since it seems like a lot more than I need
and I really wanted to be Tapestry centric and use HiveMind eventually.
Our situations are not identical, but the approach I took was to to
call Session.update(kitten) during the pageBeginRender method.
I am currently using this approach on any persistent properties and any
other properties that need to be reattached.
The gotcha I ran into has to do with the pageBeginRender being called
on render and rewind, so I added a check to only attach on the initiial
request, not the rewind. I may have that mixed up at the moment though,
so don't take my word for it.
Sorry I'm not more definitive but I am also trying to establish a
Hibernate/Tapestry best practices, just not with Spring.
Using Spring you are probably using the OpenSessionInView filter,
whereas I opted to handle my hibernate transactions and sessions in a
custom Engine class in the setupForRequest and cleanupAfterRequest
methods as someone recommended on hibernate.org somewhere. I had to use
the reattach in pageBeginRender technique to avoid lazy collection
exceptions, as well as to get cascading to work. Since my transactions
always begin and end in a single request then each page, including
re-displayed validation error pages need to reattach objects they are
going to work with. I'm not sure how that translates to Spring though.
Hope that helps. I'd be glad to post my current draft of "best
practices" if you think it would be helpful.
-Ryan Owens
On Feb 22, 2005, at 1:22 PM, Shawn Church wrote:
> I am moving forward with integrating Hibernate and Tapestry, and I have
> now added Spring into the mix. I've eliminated lazy initialization
> exceptions (so far), but I'm now trying to establish a set of best
> practices for working with detached objects. Here's a simple
> description of what I'm trying to do:
>
> 1. Load an object graph (ie - Cat, one-to-many with Kittens).
> 2. setCat(cat) abstract method
> 3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
> 4. <a jwcid="@DirectLink" listener="ognl:listeners.kittenSelectAction"
> parameters="ognl:kitten">
> 5. In kittenSelectAction(), Kitten kitten = (Kitten) parameters[0];
> 6. setKitten(kitten) abstract method (same page as before)
> 7. Render page again, showing previous (persistent) kitten list (as
> before), but now editing the selected kitten.
> 8. Input a new kitten property (ie - kitten.name)
> 9. Form submit handler validates everything and updates the edited
> kitten.
>
> This last step is where I am unsure of the best method. My Hibernate
> mappings are set to cascade save-update, and I would like to update the
> Kitten (along with any other updates which may have been made to Cat)
> with getCatService().save( getCat()).
>
> Since the original kitten instance would have been serialized and
> deserialized, I need to reassociate the detached Kitten with the Cat
> object graph. It works fine to explicitly save the Kitten (ie -
> getKittenService().save( getKitten()), but I have to be careful not to
> save the Cat without first re-fetching the kitten list. This also
> doesn't take full advantage of Hibernate's cascading update.
>
> Is this the point of using Session.update() or Session.lock()? If so,
> where is the best place (and time) to do this? I would rather keep
> this
> out of the page controller if possible.
>
> I also realize there are other/better ways of performing the above
> sequence, but since this exploits Tapestry's capabilities I would like
> to find a clean way of implementing this.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Detached object management
Posted by Henri Dupre <he...@gmail.com>.
I'm currently developing a website with Spring + Hibernate 3 + Tapestry.
I discovered recently in Hibernate 3 the session.merge(Object object).
This recreates a new persistent object using an another one. This
seems to be the only way to reload properly an object and allow lazy
loading of attached persistent collections.
That far I'm trying to have everything loading lazily and I'm
reloading the object using merge only when I run into
LazyInitialization troubles.
On Tue, 22 Feb 2005 10:22:18 -0800, Shawn Church <sh...@boxity.com> wrote:
> I am moving forward with integrating Hibernate and Tapestry, and I have
> now added Spring into the mix. I've eliminated lazy initialization
> exceptions (so far), but I'm now trying to establish a set of best
> practices for working with detached objects. Here's a simple
> description of what I'm trying to do:
>
> 1. Load an object graph (ie - Cat, one-to-many with Kittens).
> 2. setCat(cat) abstract method
> 3. @base:For source="ognl:cat.kittenList" value="ognl:kitten"
> 4. <a jwcid="@DirectLink" listener="ognl:listeners.kittenSelectAction"
> parameters="ognl:kitten">
> 5. In kittenSelectAction(), Kitten kitten = (Kitten) parameters[0];
> 6. setKitten(kitten) abstract method (same page as before)
> 7. Render page again, showing previous (persistent) kitten list (as
> before), but now editing the selected kitten.
> 8. Input a new kitten property (ie - kitten.name)
> 9. Form submit handler validates everything and updates the edited kitten.
>
> This last step is where I am unsure of the best method. My Hibernate
> mappings are set to cascade save-update, and I would like to update the
> Kitten (along with any other updates which may have been made to Cat)
> with getCatService().save( getCat()).
>
> Since the original kitten instance would have been serialized and
> deserialized, I need to reassociate the detached Kitten with the Cat
> object graph. It works fine to explicitly save the Kitten (ie -
> getKittenService().save( getKitten()), but I have to be careful not to
> save the Cat without first re-fetching the kitten list. This also
> doesn't take full advantage of Hibernate's cascading update.
>
> Is this the point of using Session.update() or Session.lock()? If so,
> where is the best place (and time) to do this? I would rather keep this
> out of the page controller if possible.
>
> I also realize there are other/better ways of performing the above
> sequence, but since this exploits Tapestry's capabilities I would like
> to find a clean way of implementing this.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org