Re: EODisplaygroup sorting in database
Re: EODisplaygroup sorting in database
- Subject: Re: EODisplaygroup sorting in database
- From: Art Isbell <email@hidden>
- Date: Mon, 4 Apr 2005 13:08:58 -1000
On Apr 4, 2005, at 12:42 PM, Alexandre Mainville wrote:
Trying to work this out, I came across something strange. I started using EOAdaptorDebugEnabled to trace the SQL calls and I noticed that on an update every field in the table is used in the WHERE clause.
customer_id is a primary key for this table, it would have been sufficient on it's own, is this normal behavior for EOF or do I have something misconfigured?
The attributes in your "where" clause are the primary key and those that you marked as class properties in your eomodel. Including class properties in a "where" clause is EOF's optimistic locking implementation. If any other process has updated any class property in the database since your process fetched the object being updated, your changes will fail to save to the database throwing an optimistic locking failure exception. If an optimistic locking failure could occur in your app, you should deal with such failures in your Java code.
Because your choice of class properties defines which properties are used for optimistic locking, you should consider which properties you wish to include. Some databases prohibit certain datatypes from being used in "where" clauses, so you shouldn't mark these as class properties. You can also run into optimistic locking failures due to rounding errors, so you should consider whether you want to include floating-point numeric types, high-precision timestamps, etc. BLOBS, long text datatypes, etc. may not be appropriate class properties.
Aloha,
Art
_______________________________________________
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