Well, even if i do:
league = new League();
league.setName("repeated name");
I still have same problem, even without that piece of code.
Everything works fine with Create/Update of entity if saveorupdate
doesn't violate any constraint.
On Sat, Sep 12, 2009 at 7:34 PM, Kalle Korhonen
<kalle.o.korho...@gmail.com> wrote:
> Yes, but the problem originates from this:
> if (entity.getId().longValue() == 0l) {
> league.setId(null);
> }
> You can't make that league object a new entity just by nullifying it's
> id. Try creating a new league if you need to. Later on, since the
> saveOrUpdate failed, the null id causes the problem in
> DefaultHibernateDAO because that object is already Hibernate's
> session.
>
> Kalle
>
> On Sat, Sep 12, 2009 at 8:47 AM, Bruno Santos <bitbet...@gmail.com> wrote:
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
