Because if you use "get" and then update that object, you're completely circumventing the optimistic locking (if you've got that enabled).
-----Original Message----- From: Lane, Geoffrey [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 12:14 PM To: Tapestry users Subject: RE: Tapernate Usage Questions So why merge? Why not have an annotation like 'reattach-get' that will get an object fresh from the database? Would that solve the problem of not having to set the value to null? In part we're trying to think about canceling forms. If you cancel, using a Page link (or just navigate away from a form) the old object state will still be in the Session and so will be merged back into the Hibernate Session if the user goes back to the form right? If that object has changed or the user has edited part of the object graph in another form, the old object state will "overwrite" the current correct state right? If you cancel using a listener and null out the object, what happens if a user clicks the back button? A persistent property that is expected on the page will be null. Thanks again for helping me understand this stuff. -- Geoff Lane <[EMAIL PROTECTED]> Ph: 414 290-8031 -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:15 AM To: 'Tapestry users' Subject: RE: Tapernate Usage Questions For reattach-merge, you need to make sure you set your persisted property to null once you're done with it, or else it'll continually merge it in. Does that make sense? -----Original Message----- From: Lane, Geoffrey [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 10:55 AM To: users@tapestry.apache.org Subject: Tapernate Usage Questions Hi, (I'm new to the list) We've been porting an application to Tapestry 4 and trying to integrate Tapernate at the same time to allow us to do lazy-loading of Hibernate objects, etc. One issue we are having is that Tapernate appears to be merging old object state back into our Hibernate session after we save the Hibernate object which in a transaction-per-request will cause the session to be dirty again and the object to be flushed with the stale state. If we turn off transaction-per-request, then normally the object will not be flushed, but the stale values are merged back into the Hibernate session again which means when the user navigates to the edit page, they will not see the correct values as they are in the database. Example Scenario: We have a Table of Divisions (an organizational unit) with edit links to navigate to an edit form. Also on every page we have a drop-down list of all of the Divisions so that a user can change their effective division. Component 1 - DivisionNavigation - list of available Divisions (in the Border component so it's on every page) Component 2 - DivisionTable - table of Divisions with some information and edit links Page - Edit Division - set the object from the edit listener in the DivisonTable and cycle.activate the Edit page We are marking the collection of Divisions in the DivisionNavigation and DivsionTable as @Persist("entity") as well as the object that's being edited in the Page. Is this just wrong? I noticed the newer version of Tapernate has different persist annotations. Any guidance as to what would be best for this kind of situation where you might have the object more than once on a page? Just looking for some guidance (and/or abuse if we're doing something obviously stupid). Thanks in advance. -- Geoff Lane <[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] --------------------------------------------------------------------- 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]
