A date time is actually a bad attribute to lock on some databases. Timestamps have nanosecond resolution, but some databases are not that accurate. So you end up with a value that is slightly off from what is stored resulting in locking exceptions. I think MSSQL is one of these databases.
But to get to your point, yes you can do that. Locking says that this attribute value is important. If you lock a single column and update it every time you save in willUpdate() you're saying that ALL attribute changes are important.
However, you then become dependent on application logic doing that. If someone comes in and edits values with a DB tool and does not increment the 'version' column, then those changes can get wiped out by a save from the app.
In your case, unless it's the timestamp thing, I don't *think* locking is your problem, because you're the only person editing the data. When you get the exception, if you do a select in the database with the qualifier values, does it return the row? If it does, then it's probably not a locking exception.
Ramsey
On Jan 12, 2012, at 9:11 AM, James Cicenia wrote: Ok --
So, why would I need more than one lock? Why not just a modified date?
James
PS: "legacy" Been awhile since I have been to apples docs. Not a good thing to first show a client!
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
|