hi oliver,
thanks for your patches. i just commited them to the repository.
your testcases pass.
jakob
[EMAIL PROTECTED] wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
