Well, if the watch is working, it's working. What I would like to know is: If the watch is first labeled as non water-resistant, why did it survive the test? If it's put in oil, will it survive too?
I guess what I am trying to say is that: If something is not meant to work and it works, maybe it's something in the code that is easy to change in order to prevent the scenario from happening. Consider this. You are building a safe that is meant to keep someone from breaking into it. If one succeeds in breaking the safe using a technique you have not thought of, wouldn't you want to modify the safe to prevent that from happening again? Oh well, I suppose in our case, Castor is an open source project and everyone is busy with their own work anyway. So, ignore my previous post if it's not an important to-do item. Thanks Keith C > -----Original Message----- > From: Thomas Yip [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 21 October 2001 7:33 p.m. > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Found JDO bug > > > > > >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 > > > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
