Re: EODisplaygroup sorting in database
Re: EODisplaygroup sorting in database
- Subject: Re: EODisplaygroup sorting in database
- From: Drew Thoeni <email@hidden>
- Date: Tue, 5 Apr 2005 07:02:47 -0400
I have also found that FLOATs should be unlocked due to some database's non-exact value storage (e.g. 2.5 being stored or returned as 2.49999998), or due to JAVA's ability to handle these as exact values, not sure which. But, I am sure the effect is WO thinks the value is different that what it is expecting and UPDATE fails.
On Apr 4, 2005, at 7:40 PM, Robert Walker wrote:
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.
One minor correction to the above. You can control optimistic locking independently of class properties. Optimistic locking is controlled by the "Locking" column in your model (this will display a lock symbol in the column). The class properties column has a diamond symbol in it. Basically if there is a lock system in the "Locking" column the attribute will be included in the WHERE clause. Otherwise it will not, even if the attribute is marked as a class property. I typically turn off optimistic locking on DOUBLE, DATETIME, BLOB & TEXT data types.
There is a good section explaining how to deal with optimistic locking in your Java code in the "Enterprise Objects" document. Check it out when you get a chance. If anyone is interested in a sample implementation of this please contact me off-list.
On Apr 4, 2005, at 7:08 PM, Art Isbell wrote:
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
--
Robert Walker
www.robertwalker1.com
"There are 10 kinds of people in the world. Those who think binary and those who don't."
_______________________________________________
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
_______________________________________________
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