You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Mike Kienenberger <mk...@gmail.com> on 2006/04/12 20:39:27 UTC
new 1.2-M11 bug: "uniquing" seems broken
I will try this again in a moment with the latest SVN snapshot, but
uniquing appears to be broken. Has this been fixed since 1.2-M11?
I have two instances of <ObjectId:Address, ADDRESS_ID=1683> in both
the modified and committed state in the same data context.
this= Address (id=145)
objectContext= DataContext (id=158)
objectId= ObjectId (id=163)
persistenceState= 3
snapshotVersion= -9223372036854769899
values= HashMap (id=165)
arg0= Address (id=90)
objectContext= DataContext (id=158)
objectId= ObjectId (id=170)
persistenceState= 4
snapshotVersion= -9223372036854769889
values= HashMap (id=171)
if (contact.getMailingAddress().equals(mailingAddress))
this= Address (id=145)
{<ObjectId:Address, ADDRESS_ID=1683>; committed;
[contactPhysicalAddressList=>?; contactMailingAddressList=>(..);
description=>Mailing; streetAddress=>660 Farmers Loop Rd. Fbks, Ak
99712; streetNumber=>null; zip=>null; contactOtherAddressList=>?;
city=>null; apt=>null]}
arg0= Address (id=90)
{<ObjectId:Address, ADDRESS_ID=1683>; modified; [stateProvince=>?;
contactPhysicalAddressList=>?; contactMailingAddressList=>?;
description=>Mailing; streetNumber=>null; streetAddress=>660 Farmers
Loop Rd. Fbks, Ak 99712; zip=>null; contactOtherAddressList=>?;
city=>null; apt=>null]}
Re: new 1.2-M11 bug: "uniquing" seems broken
Posted by Mike Kienenberger <mk...@gmail.com>.
On 4/12/06, Mike Kienenberger <mk...@gmail.com> wrote:
> create contact. create mailing address. associate. commit.
>
> lookup contact. lookup mailing address. Change mailing address
> description field. Compare to contact addresses.
>
> At this point contact has one committed copy of mailing address while
> the current mailing address is modified.
I changed things to avoid an unnecessary description field
modification. I still get the same problem, but now both objects are
in a committed state:
{<ObjectId:Address, ADDRESS_ID=1883>; committed;
[contactPhysicalAddressList=>?; contactMailingAddressList=>(..);
description=>Mailing; streetAddress=>660 Farmers Loop Rd. Fbks, Ak
99712; streetNumber=>null; zip=>null; contactOtherAddressList=>?;
city=>null; apt=>null]}
org.objectstyle.cayenne.access.DataContext@14d659d
{<ObjectId:Address, ADDRESS_ID=1883>; committed; [stateProvince=>?;
contactPhysicalAddressList=>?; contactMailingAddressList=>?;
description=>Mailing; streetNumber=>null; streetAddress=>660 Farmers
Loop Rd. Fbks, Ak 99712; zip=>null; contactOtherAddressList=>?;
city=>null; apt=>null]}
<ObjectId:Address, ADDRESS_ID=1883>
Re: new 1.2-M11 bug: "uniquing" seems broken
Posted by Mike Kienenberger <mk...@gmail.com>.
On 4/12/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> Can't say whether this was fixed, as I didn't know it was broken :-)
Yeah, I wanted to know if it was a known bug. Guess not.
> Seriously, it is worth trying with the latest CVS version, as the
> access stack is very different between the two.
Looks like it is still broken -- see below.
> If this still occurs, do you know what scenario causes it?
I'm converting sets of data. I start with an empty database. During
one record set, I create a new contact record and I create a mailing
address and assign it to the contact. This is a to-one relationship.
This record set gets committed.
Later, I convert another record set with the same contact info. I
find the contact record in the database. I find the mailing address
in a separate database query. I then try to verify that this mailing
address is not in the existing contact -- this is where the situation
above was uncovered.
So basically:
create contact. create mailing address. associate. commit.
lookup contact. lookup mailing address. Change mailing address
description field. Compare to contact addresses.
At this point contact has one committed copy of mailing address while
the current mailing address is modified.
=================================================
State with the latest cvs snapshot (which doesn't trigger CAY-501 --
dependent key commits are working for me)
this= Address (id=180)
objectContext= DataContext (id=169)
objectId= ObjectId (id=181)
persistenceState= 3
snapshotVersion= -9223372036854770911
values= HashMap (id=182)
arg0= Address (id=76)
objectContext= DataContext (id=169)
objectId= ObjectId (id=184)
persistenceState= 4
snapshotVersion= -9223372036854770899
values= HashMap (id=185)
{<ObjectId:Address, ADDRESS_ID=1783>; committed;
[contactPhysicalAddressList=>?; contactMailingAddressList=>(..);
description=>Mailing; streetAddress=>660 Farmers Loop Rd. Fbks, Ak
99712; streetNumber=>null; zip=>null; contactOtherAddressList=>?;
city=>null; apt=>null]}
{<ObjectId:Address, ADDRESS_ID=1783>; modified; [stateProvince=>null;
contactPhysicalAddressList=>?; contactMailingAddressList=>?;
description=>Mailing; streetNumber=>null; streetAddress=>660 Farmers
Loop Rd. Fbks, Ak 99712; zip=>null; contactOtherAddressLi
Re: new 1.2-M11 bug: "uniquing" seems broken
Posted by Mike Kienenberger <mk...@gmail.com>.
Andrus,
I assigned CAY-503 even though I'm still trying to track down the
problem myself.
If you see that I've reached a point where the answer is obvious,
please let me know :) Or if I'm heading down the wrong path.
It looks like to me that the problem is that ObjectId equals() or
hashCode() is broken.
Re: new 1.2-M11 bug: "uniquing" seems broken
Posted by Andrus Adamchik <an...@objectstyle.org>.
Can't say whether this was fixed, as I didn't know it was broken :-)
Seriously, it is worth trying with the latest CVS version, as the
access stack is very different between the two. If this still occurs,
do you know what scenario causes it?
Andrus
On Apr 12, 2006, at 10:39 PM, Mike Kienenberger wrote:
> I will try this again in a moment with the latest SVN snapshot, but
> uniquing appears to be broken. Has this been fixed since 1.2-M11?
>
> I have two instances of <ObjectId:Address, ADDRESS_ID=1683> in both
> the modified and committed state in the same data context.
>
> this= Address (id=145)
> objectContext= DataContext (id=158)
> objectId= ObjectId (id=163)
> persistenceState= 3
> snapshotVersion= -9223372036854769899
> values= HashMap (id=165)
> arg0= Address (id=90)
> objectContext= DataContext (id=158)
> objectId= ObjectId (id=170)
> persistenceState= 4
> snapshotVersion= -9223372036854769889
> values= HashMap (id=171)
>
>
>
> if (contact.getMailingAddress().equals(mailingAddress))
>
> this= Address (id=145)
>
> {<ObjectId:Address, ADDRESS_ID=1683>; committed;
> [contactPhysicalAddressList=>?; contactMailingAddressList=>(..);
> description=>Mailing; streetAddress=>660 Farmers Loop Rd. Fbks, Ak
> 99712; streetNumber=>null; zip=>null; contactOtherAddressList=>?;
> city=>null; apt=>null]}
>
>
> arg0= Address (id=90)
>
> {<ObjectId:Address, ADDRESS_ID=1683>; modified; [stateProvince=>?;
> contactPhysicalAddressList=>?; contactMailingAddressList=>?;
> description=>Mailing; streetNumber=>null; streetAddress=>660 Farmers
> Loop Rd. Fbks, Ak 99712; zip=>null; contactOtherAddressList=>?;
> city=>null; apt=>null]}
>