Hello Armin,
> -----Original Message-----
> From: Armin Waibel [mailto:[EMAIL PROTECTED]]
[..]
> > A potential fix is in TransactionImpl, line 883
[..]
I tried the fix myself, and this is what I needed to correct
moreover:
800c800,801
< Object[] refPkValues =
getBroker().serviceBrokerHelper().getKeyValues(rds.getClassDescriptor(),
ref, false); // modified by oma, 29.01.03
---
> Identity refOID = new Identity(ref, getBroker());
> Object[] refPkValues = refOID.getPrimaryKeyValues();
882c883
< Object[] objPkValues =
this.getBroker().serviceBrokerHelper().getKeyValues(cld, newTxObject,
false); // modified by oma, 29.01.03
---
> Object[] objPkValues =
this.getBroker().serviceBrokerHelper().getKeyValues(cld, newTxObject);
(When you read this mail, you probably have some extra linefeeds in it.
Sorry for that, I have to use M$-Outlook and I do not know how to tune
it correctly.)
> > 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.
I am going to do so.
> 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))
That is the changed I had suggested earlier in this thread, isn't it?
I feel uncomfortable with it, because it might change the behaviour
elsewhere. Somebody should investigate whether Identity is supposed
to have the converted or non-converted fields.
So I would weakly argue in favour of the above changes
to TransactionImpl.
> 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?
The impact of changing class Identity is unforseeable to me,
but I am a newbie.
Regards,
Olli
> ----- 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(UnsafeLongFieldAcc
> essorImpl.
> java
> > :84)
> > at java.lang.reflect.Field.set(Field.java:519)
> > at
> >
> org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDefa
> ultImpl.se
> t(Pe
> > rsistentFieldDefaultImpl.java:147)
> > at
> >
> org.apache.ojb.odmg.TransactionImpl.assertFkAssignment(Transac
> tionImpl.j
> ava:
> > 816)
> > at
> >
> org.apache.ojb.odmg.TransactionImpl.assignReferenceFKs(Transac
> tionImpl.j
> ava:
> > 841)
> > at
> > org.apache.ojb.odmg.TransactionImpl.lock(TransactionImpl.java:260)
> > at
> >
> org.apache.ojb.odmg.TransactionImpl.lockCollections(Transactio
> nImpl.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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
