I have also seen this problem.
I need to investigate further on order to answer all the question you
have, but the following is what I do know so far:
- Type of primary key: int (primitive). I haven't tried changing it
to a wrapper type yet.
- The instance is indeed serialized and deserialized before it is
merged.
When I get a chance I will try to answer the other questions, and put
together a small test case that reproduces the problem.
- Eric Zoerner
On Jul 15, 2007, at 9:24 PM, Marc Prud'hommeaux wrote:
Uri-
Can you answer a few questions to help us narrow this down?
1. What is the type of the primary key? If it is a primitive, and
you change it to be a wrapper type (e.g., java.util.Long instead of
long), does it change anything?
2. Does this happen for all key values you have tried, or is there
a specific one for which it fails? Specifically, I am wondering if
this happens with id=0 (which we have had some problems with
historically).
3. Is the instance being serialized/deserialized before it is
getting merged?
4. If you enable SQL logging, do you see any lookups being
attempted when you call merge()?
On Jul 15, 2007, at 9:54 AM, Uri Boness wrote:
Hi,
the entityManager.merge() doesn't seem to work properly (at least
according
to the spec). Let's say I have a Person record in the database
with id = 1.
According to the spec, when merging a new instance of a person
with an
existing id (in this case id = 1), the entityManager should figure
out that
this id already exists in the database and try to update the existing
record. Currently, merge tries to add a new record to the
database, an
operation that obviously fails due to primary key constraint
violation. Any
idea why this is happening? do I need to set up certain properties
to get it
working correctly (note: I ran the same code under hibernate and
toplink-essentials and in both cases it works fine).
cheers,
Uri
