A similar problem was identified for byte[] PKs (http://
objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-323). It was shown
that the problem is in Util.nullSafeEquals() not doing deep array
comparison. However I've never seen it happen for the int ObjectIds.
So it must be something else.
Do you have a test case that I can run to reproduce it?
Andrus
On Jun 11, 2005, at 4:38 PM, Mikaël Cluseau wrote:
> Le samedi 11 juin 2005 à 13:24 -0400, Andrus Adamchik a écrit :
>
>>> I'm writing an automated CRUD tester for Cayenne (I will contribute
>>> it ;-)).
>>>
>>
>> This would definitely be extremely handy.
>>
>
> That will be done soon then :-)
>
>
>>> 1. I create a DataObject (mandatory attributes and relationships
>>> are filled with random values).
>>>
>>
>> I assume there is a "1.5. commit"?
>>
>
> There are commits after each modifying step: create, commit, refetch,
> update, commit, delete, commit (and a hidden cleanup, commit). I
> updated
> to the latest CVS version. I traced the code deeper this time :-)
> and I
> think I've found why I have this problem.
>
> For some reason I still need to find, Cayenne wishes to replace the
> object's PK with the same value. The problem is that then, it does the
> following code, lines 604 and 605 of ObjectStore.java :
>
> objectMap.remove(id);
> dataRowCache.forgetSnapshot(id);
>
> And since the new ObjectId is the same as the old one, it effectively
> removes the objet for the cache. The update is (id is the primary
> key) :
>
> UPDATE schema.table SET id = ?, [...] WHERE id = ?
> [bind: 10001, [...], 10001]
>
> I checked, I never touch the PK, so I really don't get when Cayenne
> changes it... I'm using PostgreSQL, if there anything with the adaptor
> to check. Any idea?
>
>
This archive was generated by hypermail 2.0.0 : Mon Jun 13 2005 - 19:42:59 EDT