Re: lockRowComparingAttributes (yet again)
Re: lockRowComparingAttributes (yet again)
- Subject: Re: lockRowComparingAttributes (yet again)
- From: Chuck Hill <email@hidden>
- Date: Thu, 4 Aug 2005 22:10:05 -0700
Hi Ian,
On Aug 4, 2005, at 5:55 PM, Ian Joyner wrote:
Many thanks Chuck. Indeed I had keys defined wrong. I had always
thought it strange these were reported as a real and you confirmed my
suspicions. I don't quite know what example I followed back in the
dark mists of time, but I had Value Type set to double ('d'). Athough
this bothered me at the time, it had always seemed to work OK and the
problem hadn't been manifesting itself until this week – the rounding
error on a floating point number would explain why the behaviour was
erratic.
Luckily, I had keys (and all other data type fields defined as
prototypes in the EOPrototype table, so I only had to make two changes
to affect all the keys throughout the models. (Hence there shouldn't
be any type mismatches between keys anyway.)
You have to like prototypes!
Now I have keys defined as "Value Class = NSNumber", "External Type =
longlong" (using Openbase), "Value Type = i" ("Internal Data Type =
Integer").
I use Value Type = l for long, java.lang.Long.
I think longlong and long are just the same at 64 bit values (but can
I find any reference documentation to tell me that?), but I want to
make sure that a database can run for 100 years without problems.
Openbase also uses longlong for its row_id.
I'm pretty sure (but not 100% positive) that longlong and Long are
compatible in terms of maximums. They are darn large in any case. As
for 100 years... that depends on the frequency of inserts.
So my question is – is this a correct definition for primary keys, and
what do the experts recommend with the years of experience?
HTH
Chuck
On 05/08/2005, at 1:41 AM, Chuck Hill wrote:
On Aug 4, 2005, at 12:48 AM, Ian Joyner wrote:
OK, I have read all the past mails on this issue trying to solve
this problem. I have a person entity where generic person attributes
are stored in a PERSON table and specific attributes are stored in a
subclass table (called ASSET). I create and store one of these
entities, then add a telephone number for them (stored in a separate
TELEPHONE table). The SQL generated for the original save is:
[2005-08-04 17:13:03 EST] <WorkerThread1> evaluateExpression:
<com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression:
"INSERT INTO ASSET(HEALTH_FUND_NUMBER, PRIMARY_KEY,
HEALTH_FUND_EXPIRY_DATE, PLAYER_NUMBER, HEALTH_FUND, ASSET_TYPE_KEY,
MEDICAL_EXPIRY_DATE, MEMBER_ID, IS_A_DOCTOR, CLUB, MEDICAL_NUMBER,
IS_A_MANAGER) VALUES (NULL, ?, NULL, NULL, NULL, ?, NULL, NULL,
NULL, NULL, NULL, NULL)" withBindings: 1:4(primary_key),
2:13.0(asset_type_key)>
When I attempt to save the new telephone record, I get:
[2005-08-04 17:13:24 EST] <WorkerThread3> evaluateExpression:
<com.webobjects.jdbcadaptor.OpenBasePlugIn$OpenBaseExpression:
"SELECT t0.PRIMARY_KEY FROM ASSET t0, PERSON T1 FOR UPDATE
That right there looks wrong. SELECT...FOR UPDATE strongly suggests
that something is wrong with your model. The first two things to
check are:
1. Are the Value Type and Value Class (Java) set / set correctly for
each attribute in the table?
2. Have you recently switched databases and have the old jdbc2info in
the model's connection dictionary?
3. Do the PK / FK definitions on the keys in Person, Asset, and
Telephone match _exactly_? Exactness counts. :-)
I'd guess that you have a mismatch between the model and your
database or between the PK or FK definitions on two related entities.
Check the Scale and Precision. Is asset_type_key really supposed to
be a floating point number? This error will happen if you are using
BigDecimal and the Scale as created does not match the Scale as
fetched or if you do math and the scale is not set correctly on the
result.
[2005-08-04 17:13:24 EST] <WorkerThread3>
com.webobjects.eoaccess.EOGeneralAdaptorException:
lockRowComparingAttributes --
com.webobjects.jdbcadaptor.JDBCChannel: lock operation fetched row
with different values than snapshot
at
com.webobjects.eoaccess.EODatabaseContext._exceptionWithDatabaseConte
xtInformationAdded(EODatabaseContext.java:4686)
at
com.webobjects.eoaccess.EODatabaseContext.performChanges(EODatabaseCo
ntext.java:6394)
at
com.webobjects.eocontrol.EOObjectStoreCoordinator.saveChangesInEditin
gContext(EOObjectStoreCoordinator.java:415)
lockRowComparingAttributes has found a single record, so that is OK,
but it must fail on the comparison.
Now I have also turned off attribute locking on every attribute,
That is not going to help. The error is not "can't find the row in
the DB" but "found the row and the values fetched don't match the
values previously cached". Note this is ALL the values not just what
is in the WHERE clause. From your description, this is a modeling /
code error, not a true optimistic locking failure (well, unless
something else is writing to the DB).
Test it out like this: insert a new object. Stop and restart the
app. Edit the object. Does that go OK? If so, the error is in your
model / code.
Chuck
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden