There is a simpler solution that works is to rollback the DB transaction in case validation fails. So we are actually get a transaction from the Hibernate session and roll it back therefore no changes are efficient in the session. There is not very flexible solution but works for simpler cases. There are different solution, e.g. working on detached objects or clearing session.
Renat On 30/10/2007, Maximilian Weißböck <[EMAIL PROTECTED]> wrote: > > Oh yes, this is really a problem we actually had in a Tapestry 4 > Application. We had to use (ugly) DTO Objects to avoid this problem. > > As far as I can remember, this problem is addressed in JSF with its > complex > render cycle. Values are stored in intermediate objects until > validation is completed and only then are copied to the bean data object. > > Would be interesting if there could be a similar soultion for T5? > > Max > > > > -----Ursprüngliche Nachricht----- > > Von: lasitha [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 30. Oktober 2007 15:29 > > An: Tapestry users > > Betreff: Re: T5: Tapestry-Hibernate, do we have to save()? > > > > On 10/30/07, Angelo Chen <[EMAIL PROTECTED]> wrote: > > > > > > is this really needed? I got confused, why the changes are > > saved without > > > calling _session.save()? > > > > Angelo, this is default hibernate behaviour. See: > > http://www.hibernate.org/hib_docs/v3/reference/en/html/objects > > tate.html#objectstate-modifying > > > > However, your post brings up an interesting question: will the > > object's state be persisted even after validation fails? My first > > guess is might actually be a problem. > > Consider: > > 1. Object is retrieved in onAttached() and associated with a > > new session, > > 2. Fields are updated with values from the form submission (lets > > assume they are valid), > > 3. Some cross-validation fails in onValidate() - so onSuccess() is > > never called, but... > > 4. As the thread cleans up, the HibernateSessionManager commits the > > transaction anyway and the invalid values are persisted! > > > > I'd like to test this and look around the lists a bit but am throwing > > this out in case others have thoughts. > > > > Cheers, lasitha. > > > > --------------------------------------------------------------------- > > 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] > > -- Best regards, Renat Zubairov
