Thanks for the patch, Andrus.
My test program managed to get further along, but now it seems as if the
relationships are still wrong. In our model, we have a "Pool" entity
joined to an "APNPoolNumber" entity and fetch the Pool through the
relationship based upon the "apnPoolNumber" attribute in the
APNPoolNumber table (which works):
DEBUG QueryLogger: SELECT t0.identifier, t0.isAssumable, t0.isBalloon,
t0.numberPID FROM Pool t0, APNPoolNumber t1
WHERE t0.numberPID = t1.identifier AND (t1.apnPoolNumber = ?) [bind:
'461105'] - prepared in 31 ms.
DEBUG QueryLogger: === returned 1 row. - took 81 ms.
Pool = {[ isAssumable => false
isBalloon => true
identifier => [..9ce8c
number => {<oid: test.APNPoolNumber: <identifier: [..eea66>;
state: hollow>}
]<oid: test.Pool: <identifier: [..9ce8c>; state: committed>}
I'm guessing that "committed" = saved and "hollow" = fault. So, it
fetched in the Pool via a join with the APNPoolNumber table and has a
fault for the actual APNPoolNumber object, which is cool. Then I tried
using pool.getNumber().getApnPoolNumber() and
pool.readNestedProperty("number.apnPoolNumber"), both of which returned
a null, but logged this SQL:
INFO QueryLogger: --- will run 1 query.
INFO QueryLogger: SELECT t0.apnPoolNumber, t0.identifier FROM
APNPoolNumber t0
WHERE t0.identifier = ? [bind: < 80 80 80 80 80 80 80 A2 CC 20 EE C9 >]
INFO QueryLogger: === returned 1 row. - took 20 ms.
INFO QueryLogger: --- will run 1 query.
INFO QueryLogger: SELECT t0.apnPoolNumber, t0.identifier FROM
APNPoolNumber t0
WHERE t0.identifier = ? [bind: < 80 80 80 80 80 80 80 A2 CC 20 EE C9 >]
INFO QueryLogger: === returned 1 row. - took 10 ms.
Then I tried logging pool.getNumber() and it was also null. So, then I
tried loading the APNPoolNumber entity directly, which gave me:
DEBUG QueryLogger: --- will run 1 query.
DEBUG QueryLogger: SELECT t0.apnPoolNumber, t0.identifier FROM
APNPoolNumber t0 WHERE t0.apnPoolNumber = ? [bind: '461105']
DEBUG QueryLogger: === returned 1 row. - took 10 ms.
APNPoolNumber = {[ apnPoolNumber => 461105
]<oid: test.APNPoolNumber: <identifier: [..1eea8>; state: committed>}
This worked fine. The interesting part here is that the state is now
committed, as you would expect, but the identifier is different.
Shouldn't the identifier (which is the primary key) be the same when it
is hollow and committed?
Any thoughts?
Thanks!
/dev/mrg
PS. Also, "80 80 80 80 80 80 80 A2 CC 20 EE C9" is different than
yesterday's "[0, 0, 0, 0, 0, 0, 0, 34, 76, -96, 110, 73]" ... 0x80 !=
0. 0xA2 != 34 ...
Andrus Adamchik wrote:
> Ok, here is a link to download patched version of Cayenne 1.0.1 that
> contains the fix mentioned below:
>
>
> http://objectstyle.org/downloads/cayenne/patched/cayenne-src-1.0.x-
> dev.tar.gz
>
> Officially this will be released as part 1.0.2 whenever we ready to
> make this release.
>
> Andrus
This archive was generated by hypermail 2.0.0 : Wed Oct 22 2003 - 14:36:18 EDT