Hi Oliver, > Armin, you introduced the PersistenceBrokerHelper. > and in TransactionImpl, line 883, you do:
yes, I introduced "serviceBrokerHelper", but I only copied existing code wirhout any modifications (hope so ;-)). > A potential fix is in TransactionImpl, line 883 > > Object[] objPkValues > = this.getBroker().serviceBrokerHelper().getKeyValues(cld, newTxObject, > false); // added last parameter > > What do you think? I'm not familiar with jdbc/object mapping stuff in OJB. Thus I think could not be amiss ;-) > I have not tried the test case that you, Armin, have introduced. > If the test does not fail, there mightbe somethinng > wrong with the test (Missing collections?) > I currently have updated your test case, called "FieldConversion_ForeigenKeyTest" - Please check out and have a look. The test case failed without your suggested modifications (serviceBrokerHelper().getKeyValues(cld, newTxObject,false) in Identity+TransactionImpl) When I modify Identity.java (getKeyValues(cld, newTxObject,false)) your test case was passed - without modify TransactionImpl. But your argumentation makes sense, thus I will check in both files with the "getKeyValues(cld, newTxObject,false" modification. What do you mean? regards, Armin ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 10:54 AM Subject: OJB123, RE: 0.9.8, ODMG: primary key with FieldConversion > Hello, > > I am currently porting our stuff to current CSV head > (OJB 0.9.9) and I am experiencing problems with this > issue (OJB48 / OJB123). > > Armin, you introduced the PersistenceBrokerHelper. > and in TransactionImpl, line 883, you do: > > Object[] objPkValues > = this.getBroker().serviceBrokerHelper().getKeyValues(cld, newTxObject); > > In this case, the field conversion should not take place. > Since it does, I later reach > > assertFkAssignment():816, org.apache.ojb.odmg.TransactionImpl > assignReferenceFKs():841, org.apache.ojb.odmg.TransactionImpl > lock():260, org.apache.ojb.odmg.TransactionImpl > lockCollections():931, org.apache.ojb.odmg.TransactionImpl > register():782, org.apache.ojb.odmg.TransactionImpl > lock():289, org.apache.ojb.odmg.TransactionImpl > > with refPkValues[0] instanceOf java.math.BigDecimal > > which results in the follwing exception: > > 13954 ERROR [main] fieldaccess.PersistentFieldDefaultImpl - while set field: > > [...] > target field type: long > object value class: java.math.BigDecimal > [...] > 13969 ERROR [main] odmg.TransactionImpl - Locking obj [...] with lock mode 4 > failed > java.lang.IllegalArgumentException > at > sun.reflect.UnsafeLongFieldAccessorImpl.set(UnsafeLongFieldAccessorImpl. java > :84) > at java.lang.reflect.Field.set(Field.java:519) > at > org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefaultImpl.se t(Pe > rsistentFieldDefaultImpl.java:147) > at > org.apache.ojb.odmg.TransactionImpl.assertFkAssignment(TransactionImpl.j ava: > 816) > at > org.apache.ojb.odmg.TransactionImpl.assignReferenceFKs(TransactionImpl.j ava: > 841) > at > org.apache.ojb.odmg.TransactionImpl.lock(TransactionImpl.java:260) > at > org.apache.ojb.odmg.TransactionImpl.lockCollections(TransactionImpl.java :931 > ) > at > org.apache.ojb.odmg.TransactionImpl.register(TransactionImpl.java:782) > at > org.apache.ojb.odmg.TransactionImpl.lock(TransactionImpl.java:289) > > > A potential fix is in TransactionImpl, line 883 > > Object[] objPkValues > = this.getBroker().serviceBrokerHelper().getKeyValues(cld, newTxObject, > false); // added last parameter > > What do you think? > I have not tried the test case that you, Armin, have introduced. > If the test does not fail, there mightbe somethinng > wrong with the test (Missing collections?) > > Regards, > Olli > > > > -----Original Message----- > > From: Armin Waibel [mailto:[EMAIL PROTECTED]] > > > The bug you describe reside in a part of OJB that wasn't > > my special subject, thus the best thing I think is to post > > a test case. I will check in the test ASAP. > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > > > Hello, > > > want to ask again. I am pretty sure that > > this bug is due to an issuficient fix for OJB48. > > That fix just applies to the PersistenceBroker API, > > but when using the ODMG API, a different > > assertFKAssignment() method is used. > > > --------------------------------------------------------------------- > 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]
