>In the meantime, I remove the key-generator and now Castor allows
>ProductGroup to be used in the separate transaction. Is this a bug?
If one is misusing a product, s/he cannot expect any defined result.
Consider that:
After you're soaking a non water-resistance watch in water,
you found that your watch is still working.
Tell me, is the watch broken or not?
Thomas
> -----Original Message-----
>> From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>> Sent: Sunday, 21 October 2001 12:13 p.m.
>> To: [EMAIL PROTECTED]
>> Subject: Re: [castor-dev] Found JDO bug
>>
>>
>>
>> Did you reload the ProductGroup in second transaction? If you didn't, you
>> should.
>>
>> Castor is not designed for object to be reused across transaction
>> boundary.
>> Unless in special case, for long transaction support.
>>
>>
>>
>> Thomas
>>
>> -----Original Message-----
>> >From: Keith Chew SL [mailto:[EMAIL PROTECTED]]
>> >Sent: Saturday, October 20, 2001 4:03 PM
>> >To: [EMAIL PROTECTED]
>> >Subject: Re: [castor-dev] Found JDO bug
>> >
>> >
>> >Ok, new bug discovery. I have updated the latest CVS code. It
>> now works if
>> I
>> >use the key genrator.
>> >
>> >However, I manage to reproduce the same error by adding this:
>> >
>> > db.commit();
>> > db.begin();
>> >
>> >After the creation of the ProductGroup. This means that the
>> ProductGroup is
>> >created in one transaction, and assigned to the Product in another
>> >transaction.
>> >
>> >If I remove using the key-genrator, then Castor allows the separate
>> >transaction scenario.
>> >
>> >Regards
>> >Keith C
>> >
>> >
>> >> -----Original Message-----
>> >> From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>> >> Sent: Sunday, 21 October 2001 8:07 a.m.
>> >> To: [EMAIL PROTECTED]
>> >> Subject: Re: [castor-dev] Found JDO bug
>> >>
>> >>
>> >>
>> >>
>> >> I believe the problem solved a while ago. It is in the CVS.
>> >> If you don't uses autoStore(), it is user responsibility to
>> >> create object in
>> >> sequence.
>> >> If autoStore() is used, Castor walked the tree, and marked object to
be
>> >> created.
>> >> Then, it creates object that do not depends on other ids
>> first. And, the
>> >> create object depends on the created object, and so on.
>> >>
>> >>
>> >>
>> >>
>> >> Thomas
>> >>
>> >> -----Original Message-----
>> >> >From: Keith Chew SL [mailto:[EMAIL PROTECTED]]
>> >> >Sent: Saturday, October 20, 2001 7:48 AM
>> >> >To: [EMAIL PROTECTED]
>> >> >Subject: [castor-dev] Found JDO bug
>> >> >
>> >> >Hi
>> >> >
>> >> >I posted a mail recently about the Product -> ProductGroup problem
>> >> (Castor's
>> >> >example). Basically, when you:
>> >> >(1) create a ProductGroup
>> >> >(2) assign it to a new Product
>> >> >(3) create new Product
>> >> >
>> >> >Castor will extract the ProductGroups's id and insert it into
>> >> the group_id
>> >> >field. Here's the snippet of the Product's mapping:
>> >> > <!-- Product has reference to ProductGroup,
>> >> > many products may reference same group -->
>> >> > <field name="group" type="myapp.ProductGroup">
>> >> > <sql name="group_id" />
>> >> > <xml name="group" node="element" />
>> >> > </field>
>> >> >
>> >> >OK, here's the catch. If you create a key generator (I used HIGH/LOW)
>> and
>> >> >make ProductGroup use it, Castor cannot create the Product object.
The
>> >> >group_id will be left as null and the DB will complain with: "ERROR:
>> >> >ExecAppend: Fail to add null value in not null attribute
>> >> group_id" (This is
>> >> >from postgresql).
>> >> >
>> >> >To reproduce this problem just add this to the mapping.xml and create
>> the
>> >> >keys table:
>> >> >
>> >> > <key-generator name="HIGH/LOW">
>> >> > <param name="table" value="keys"/>
>> >> > <param name="key-column" value="table_name"/>
>> >> > <param name="value-column" value="max_pk_value"/>
>> >> > <param name="grab-size" value="1000"/>
>> >> > </key-generator>
>> >> >
>> >> > <!-- Mapping for ProductGroup -->
>> >> > <class name="myapp.ProductGroup"
>> >> > identity="id" access="shared" key-generator="HIGH/LOW">
>> >> > <description>Product group</description>
>> >> > <map-to table="prod_group" xml="group" />
>> >> > <cache-type type="unlimited"/>
>> >> > <field name="id" type="integer" >
>> >> > <sql name="id" type="integer"/>
>> >> > <xml node="element"/>
>> >> > </field>
>> >> > <field name="name" type="string">
>> >> > <sql name="name" type="char" />
>> >> > <xml node="element" />
>> >> > </field>
>> >> > </class>
>> >> >
>> >> >Can someone in the Castor team look into this problem please?
>> >> >
>> >> >Keith C
>> >> >
>> >> >-----------------------------------------------------------
>> >> >If you wish to unsubscribe from this mailing, send mail to
>> >> >[EMAIL PROTECTED] with a subject of:
>> >> > unsubscribe castor-dev
>> >> >
>> >>
>> >> -----------------------------------------------------------
>> >> If you wish to unsubscribe from this mailing, send mail to
>> >> [EMAIL PROTECTED] with a subject of:
>> >> unsubscribe castor-dev
>> >>
>> >>
>> >>
>> >
>> >-----------------------------------------------------------
>> >If you wish to unsubscribe from this mailing, send mail to
>> >[EMAIL PROTECTED] with a subject of:
>> > unsubscribe castor-dev
>> >
>>
>> -----------------------------------------------------------
>> If you wish to unsubscribe from this mailing, send mail to
>> [EMAIL PROTECTED] with a subject of:
>> unsubscribe castor-dev
>>
>>
>>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
