Re: lockRowComparingAttributes (yet again)
Re: lockRowComparingAttributes (yet again)
- Subject: Re: lockRowComparingAttributes (yet again)
- From: Ian Joyner <email@hidden>
- Date: Fri, 5 Aug 2005 10:55:12 +1000
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.)
Now I have keys defined as "Value Class = NSNumber", "External Type =
longlong" (using Openbase), "Value Type = i" ("Internal Data Type =
Integer").
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.
So my question is – is this a correct definition for primary keys,
and what do the experts recommend with the years of experience?
Thanks
Ian Joyner
Sportstec
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
(EODatabaseContext.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
_______________________________________________
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