The question is i'm not trying to flush anything, i do (through DAO) session.saveOrUpdate, catch the exception and the only thing i do besides registering the error on the form is returning this (the page i'm at) wich causes (i guess) tapestry to query database to fill data for selectmodels. And, at this point i think tapestry uses the same session it used for the saveorupdate and "list" trys to flush if there's "dirty data".
On Sat, Sep 12, 2009 at 3:02 AM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > I'm using the plain hibernate Session (shadow) and the pattern works > great for me. But I think your problem is actually in "(don't flush > the > Session after an exception occurs)". You are doing something odd since > you need to nullify the id. For a new object, the id should normally > be null. Tapestry is already thinking it's a previously persisted > entity. > > Kalle > > > On Fri, Sep 11, 2009 at 2:30 PM, Bruno Santos <bitbet...@gmail.com> wrote: >> Hello, >> >> Well, the reason should be that with persist in validate() i validate >> that the entity that's inserted doesn't conflict with any database >> constraint like in this case and the onsucess isn't fired wich in the >> case a constraint is violated it doesn't seem to make sense. >> >> Anyway, even if i use the code on the onSucess method it comes down to >> the same issue, the exception is thrown whenever i try to do any >> operation that requires hibernate (problem should be in >> hibernatesessionmanager, not being "clean"). >> >> One way i guess it could solve the problem is discarding the current >> hibernatesessionmanager, invalidate it somehow, but i don't know if >> that's possible. >> >> Thanks >> >> On Fri, Sep 11, 2009 at 10:15 PM, Sven Homburg <hombu...@googlemail.com> >> wrote: >>> what is your reason, that you want to persist the enity >>> in the validation event? >>> >>> i think its more clear to persist it in the onSuccess event method >>> >>> with regards >>> Sven Homburg >>> Founder of the Chenille Kit Project >>> http://www.chenillekit.org >>> >>> >>> >>> >>> 2009/9/11 Bruno Santos <bitbet...@gmail.com> >>> >>>> Thanks for your answer, i learned a bit more of tapestry. >>>> >>>> Now i have one more problem, not exactly related but in the same area. >>>> >>>> I have >>>> >>>> void onValidateForm() { >>>> if (entity.getId().longValue() == 0l) { >>>> league.setId(null); >>>> } >>>> >>>> System.out.println("OnValidateForm"); >>>> try { >>>> _entityDAO.persist(entity); >>>> } catch (RuntimeException ex) { >>>> leagueForm.recordError("error"); // EXCEPTION IS >>>> THROWN - THE TEST >>>> I'M DOING HITS THE UNIQUE CONSTRAINT >>>> } >>>> >>>> } >>>> >>>> void onFailure() { >>>> _entityDAO.abort(); >>>> System.out.println("onFailure"); >>>> } >>>> >>>> And this is working except it doesn't refresh the form with the errors >>>> i added on the onValidate >>>> >>>> When i use: >>>> >>>> Object onFailure() { >>>> _entityDAO.abort(); >>>> System.out.println("onFailure"); >>>> return this; >>>> } >>>> >>>> The following exception is thrown: >>>> >>>> Caused by: org.apache.tapestry5.ioc.internal.util.TapestryException: >>>> null id in pt.hi.asianconnect.entities.League entry (don't flush the >>>> Session after an exception occurs) [at >>>> classpath:pt/hi/asianconnect/components/generated/CreateUpdateLeague.tml, >>>> line 12] >>>> at >>>> org.apache.tapestry5.internal.bindings.PropBinding.get(PropBinding.java:62) >>>> at >>>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl$1.read(InternalComponentResourcesImpl.java:510) >>>> ... 119 more >>>> Caused by: org.hibernate.AssertionFailure: null id in >>>> pt.hi.asianconnect.entities.League entry (don't flush the Session >>>> after an exception occurs) >>>> at >>>> org.hibernate.event.def.DefaultFlushEntityEventListener.checkId(DefaultFlushEntityEventListener.java:78) >>>> at >>>> org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:187) >>>> at >>>> org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143) >>>> at >>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) >>>> at >>>> org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) >>>> at >>>> org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:58) >>>> at >>>> org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:996) >>>> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1589) >>>> at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306) >>>> at DefaultHibernateDAO.findByCriteria(DefaultHibernateDAO.java:104) >>>> >>>> >>>> The abort method from DAO was an experiment of mine wich calls >>>> hibernatesessionmanager.abort(). From what i understand, what happens >>>> is when the page is to be renderered, the hibernatesessionmanager >>>> that's used has "dirty" data that's why it uses >>>> SessionImpl.autoFlushIfRequired when i'm fetching data to refill the >>>> page, hence my experiment on calling the abort from >>>> hibernatesessionmanger, still this doesn't do it and i don't know how >>>> to "clean" data from the sessionmanager. >>>> >>>> Ideas anyone? >>>> >>>> One importante note, the test i'm doing implies that the my method >>>> that saveOrUpdate the entity is "hitting" a unique constraint >>>> >>>> On Thu, Sep 10, 2009 at 11:20 PM, Kalle Korhonen >>>> <kalle.o.korho...@gmail.com> wrote: >>>> > You should instead try storing it onValidate. If it fails, you should >>>> > record an error and if it succeeds you should commit only in onSuccess >>>> > (but the method body can be otherwise empty). >>>> > >>>> > Kalle >>>> > >>>> > >>>> > On Thu, Sep 10, 2009 at 2:55 PM, Bruno Santos <bitbet...@gmail.com> >>>> wrote: >>>> >> Good evening, >>>> >> >>>> >> I have a form using a zone and i have @CommitAfter on the >>>> >> onSubmitFromEntityForm() >>>> >> >>>> >> <t:form t:id="entityForm" zone="entityZone"> >>>> >> <input type="text" t:type="textfield" t:id="name" >>>> >> t:value="entity.name" /> >>>> >> </t:form> >>>> >> >>>> >> @CommitAfter >>>> >> Object onSubmitFromEntityForm() { >>>> >> .... >>>> >> try { >>>> >> entityDao.persist(entity); >>>> >> } catch (exception ex) { >>>> >> // handle exception >>>> >> } >>>> >> } >>>> >> >>>> >> altough i'm handling the exception the @CommitAfter creates a new >>>> >> exception since it tries to commit something that's not in transaction >>>> >> due to catched exception. >>>> >> >>>> >> How to deal with this? Is there a way to avoid the @CommitAfter to >>>> >> execute ... a handler i can use? I think i can remove the @CommitAfter >>>> >> but don't believe this should be first option. >>>> >> >>>> >> --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> >> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >> >>>> >> >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> > For additional commands, e-mail: users-h...@tapestry.apache.org >>>> > >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
