Well, I just posted it to the forum too. -----Original Message----- From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 11:27 AM To: Tapestry users Subject: RE: Insert/Update pages and Hibernate
HIbernate community practice is to submit issues for filtering in the forum first and only after that promote them to JIRA bug tracking if necessary. James Carman <[EMAIL PROTECTED]> wrote: Well, I would still consider it a bug. It's one thing to expect Hibernate to rollback values that I set on my objects during the course of a transaction. It doesn't do that. But, it's an entirely different thing to expect Hibernate to rollback values that *it* sets on my objects (or not set them in the first place if the transaction never commits). If it's causing my objects to be in a bad state (look persistent, but are not), then I say that's a bug. I've opened a Jira issue and hopefully it'll get some attention: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1716 If anyone else would like them to look at it, please vote for the issue. Thanks. -----Original Message----- From: Paul Cantrell [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 03, 2006 11:16 AM To: Tapestry users Subject: Re: Insert/Update pages and Hibernate Konstantin's idea of using the domain object itself as an edit buffer is exactly what I'm saying often leads to trouble. It *can* work -- it just ends up being unnecessarily complicated in most cases. However, I agree with him that this is *really* not a bug in Hibernate. The Hibernate team does need to have a day of serious self- reckoning about how they handle object identity (JDO got that part right, Hibernate fudged it) -- however, the particular problem you're talking about is intended and correct behavior, because: (1) you have complete control in the mapping file over how IDs are assigned, and can override that behavior with custom assignment if you want to (as I often do -- I like IDs assigned up front, and never use them as an "is persisted" indicator); and (2) what you're really worrying about is not actually IDs per se, but the fact that Hibernate does not somehow make your objects transactional and roll them back. **That is not Hibernate's job.** Again, every persistent object in the VM must eventually be persisted or discarded; there is no going back. Rollback is for the database, not your objects! Cheers, Paul P.S. Yes, Konstantin, I guess I am a little too hard on Struts. It was really the lack of squeezers I'm thinking of -- the need to manually stuff/unstuff objects every time they go to and from the client. That creates a lot of grunt work. On May 3, 2006, at 10:05 AM, James Carman wrote: > Well, I would consider it a bug. This doesn't just happen on > saveOrUpdate(). And, you don't have to flush the session to get it to > happen either. Check out the main method on this class: > > http://www.carmanconsulting.com/svn/public/tapernate/trunk/src/test/ > com/carm > anconsulting/tapernate/util/SessionFactoryFactory.java > > It prints out "The id is 1." > > -----Original Message----- > From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 03, 2006 10:56 AM > To: Tapestry users > Subject: RE: Insert/Update pages and Hibernate > > Do not think this is a 'bug'. SaveOrUpdate is a 'convenience' > feature and if > different strategy is necessary then it can be implemented /easily/ > in the > application DAO layer. > > Although I personally never needed that, saveOrUpdate magic > combined with > 'assigned' identifiers work quite well for me. > > James Carman wrote: That doesn't avoid > the > problem where the id can be set, but the row isn't > actually written to the database. The next time a request comes > in, that > object will have its id property set and Hibernate will think it's a > persistent object (when you go to merge), when it really is not. > This is > quite a nasty bug (it's a bug IMHO) in Hibernate. I wouldn't think > that it > should write the id property values until after the transaction is > really > complete. But, I haven't really thought through all of the > scenarios as I'm > sure they did. Has anyone filed a Jira issue with the Hibernate > folks about > this to get some clarification? > > > -----Original Message----- > From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 03, 2006 10:45 AM > To: Tapestry users > Subject: RE: Insert/Update pages and Hibernate > > Object itself could be such a buffer (or rather working copy of an > object) > and later it can be merged with Hibernate session /session.merge > () / when > necessary > > For the comparison fairness I simply pointed to the fact that > Struts does > not require all the object fieds to be duplicated in ActionForm as > people > often do. > > James Carman wrote: This is exactly what > they're trying to avoid, putting "business objects" > into their page logic. The problem with that, as pointed out > earlier, is > that it can leave your business objects in an invalid state (they > have an > identifier assigned to them, but the record isn't actually in the > database). > So, they're trying to come up with a "buffer" to avoid such a > situation. > > -----Original Message----- > From: Konstantin Iignatyev [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 03, 2006 1:38 AM > To: Tapestry users > Subject: Re: Insert/Update pages and Hibernate > > FYI: there is no need to 'maintain' ActionForm in Struts unless you > need to, this is the common mistake. > Business object can be placed in the ActionForm as one field and its > properties accessed and set in OGNL like fashion > via BeanUtils. > http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/ > presentation/html/i > mg19.html > http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/ > presentation/html/i > mg20.html > http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/ > presentation/html/i > mg21.html > > It is even easier with Struts' "nested" taglib > > Jim Steinberger wrote: >> Paul, thanks a lot for your insight; I'm finding it very very >> helpful. >> >> The only thing I'm really not excited about with this approach >> is the >> number of times my domain-properties are going to be repeated >> throughout >> my page classes and/or value-objects. >> After struggling to maintain Struts ActionForms in the face of >> domain-changes, seeing how HTML forms can be tied directly to >> domain-objects via OGNL in Tapestry was a big selling point behind >> getting me to switch. >> >> I'm just pouting, though -- I appreciate the necessity of a data- >> buffer >> at the UI level, particularly when dealing with a persistence >> mechanism >> that can potentially leave objects in an indeterminate state. >> >> >> Thanks again, >> Jim >> >> >> -----Original Message----- >> From: Paul Cantrell [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, May 02, 2006 10:09 PM >> To: Tapestry users >> Subject: Re: Insert/Update pages and Hibernate >> >> Jim -- >> >> My suggestion would be to keep all the user-entered values around in >> an object that's not the manufacturer, but is solely a value object >> that is very specific to this particular UI. In most cases, this is >> the page class itself: >> >> class CreateEditManufacturer extends BasePage { >> public abstract get/setName(); >> public abstract get/setFlavor(); >> public abstract get/setBossesFavoriteMarxBrother(); >> ...etc... >> >> public IPage saveManufacturer() { >> try { >> getManufacturer().setName(getName()); >> getManufacturer().setBossesFavoriteMarxBrother >> (getBossesFavoriteMarxBrother()); >> ...etc... >> getManufacturerService().createManufacturer(); >> } catch (Exception e) { >> setError("Could not create Manufacturer: " + e.getMessage >> ()); >> return this; >> } >> } >> } >> >> But perhaps you have a multi-page process or something, where it >> becomes simpler to build up the user's responses in a _value object_: >> >> class CreateEditManufacturer extends BasePage { >> @Persist("server") >> public abstract ManufacturerEntryForm get/ >> setManufacturerEntryForm(); >> >> public IPage saveManufacturer() { >> try { >> values = getManufacturerValues(); >> getManufacturer().setName(values.getName()); >> getManufacturer().setBossesFavoriteMarxBrother >> (values.getBossesFavoriteMarxBrother()); >> ...etc... >> getManufacturerService().createManufacturer(); >> } catch (Exception e) { >> setError("Could not create Manufacturer: " + e.getMessage >> ()); >> return this; >> } >> } >> } >> >> class ManufacturerEntryForm implements Serializable { // *not* >> persistable! >> ... >> } >> >> Either way, the point is that you keep the user's input in a value >> object of some kind, page or otherwise, that is -- this is the key -- >> modeled after the user interface, *not* after the domain object. The >> value object is a transcription of what the user entered. >> >> Only when you're ready to do something committable do you apply >> changes from the UI to the domain. So you're not cloning the domain >> object; you're just not eagerly applying changes to the domain at >> each step. >> >> This is not an "always the right answer" practice; it's just a >> "usually works best" practice. >> >> But yes, in any case, you're quite right: Hibernate doesn't do any >> kind of in-memory rollback on your objects! No matter what approach >> you take, you *cannot* manipulate a domain object unless you're >> prepared to either (1) commit it or (2) discard it. >> >> Cheers, >> >> Paul >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: tapestry-user- >> [EMAIL PROTECTED] >> >> >> > > > -- > Thanks, > > Konstantin Ignatyev > > http://www.kgionline.com > > > > > > PS: If this is a typical day on planet earth, humans will add fifteen > million tons of carbon to the atmosphere, destroy 115 square miles of > tropical rainforest, create seventy-two miles of desert, eliminate > between > forty to one hundred species, erode seventy-one million tons of > topsoil, add > 2.700 tons of CFCs to the stratosphere, and increase their > population by > 263.000 > > Bowers, C.A. The Culture of Denial: > Why the Environmental Movement Needs a Strategy for Reforming > Universities > and Public Schools. > New York: State University of New York Press, 1997: (4) (5) (p.206) > > > --------------------------------------------------------------------- > 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] > > _________________________________________________________________ Piano music podcast: http://inthehands.com Other interesting stuff: http://innig.net --------------------------------------------------------------------- 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]
