For most of my attributes, last in wins will be fine. Would like to avoid SQL as there are a lot of fairly complicated computations being performed so really want to stick with Java for that.
Jeff > On Mar 18, 2016, at 1:02 PM, Philippe Rabier <[email protected]> wrote: > > Jeff, if you remove the lock, you have a risk to get a write-write conflict, > aka a write replaced by another. It’s maybe not a big deal. I don’t know. > > Another solution, if you are sure your background db process is the only one > to modify an attribute, is to use raw sql to update the column you want to > modify. > > Philippe > >> On 18 mars 2016, at 17:42, Jeff Schmitz <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Chuck, >> Yep, I understand the issue with inconsistent data, but most of my >> attributes are not semantically dependent on other attributes in that way >> If that’s all the locks are guarding against I’ve got some lock trimming to >> do. >> >>> On Mar 18, 2016, at 11:11 AM, Chuck Hill <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Jeff, >>> >>> Yes, if a column is not marked as locking, then it won’t appear in the >>> WHERE clause. >>> >>> The danger is that you might save changes that are inconsistent with what >>> the database has stored in the columns that you are not locking on. As a >>> contrived example, consider the update below changing Bob to Robert. If >>> you don’t lock on first and last name, some other process might have >>> updated both names to John Edwards. Your update will now change the name >>> to Robert Edwards. You need to look at your data and see where that might >>> matter and where it does not. >>> >>> Chuck >>> >>> >>> From: <[email protected] >>> <mailto:[email protected]>> on >>> behalf of Jeff Schmitz <[email protected] >>> <mailto:[email protected]>> >>> Date: Thursday, March 17, 2016 at 5:20 PM >>> To: WebObjects Development <[email protected] >>> <mailto:[email protected]>> >>> Subject: Quick EOModel Column Locking ? >>> >>> I’m starting to get some optimistic column locking failures during >>> background db processing soI’m trying to grasp conditions under which I >>> don’t need to lock a column (i.e. put the little lock symbol in EOModeler) >>> >>> If I have a column in a table that I know is not updated (i.e. changed) by >>> any client except form my personal administrative page, can I get away >>> without locking that column? On unlocked columns is there any where >>> clause checks such as shown below before that column is updated? If not, >>> this should stop the locking errors, right? Any other dangers with this? >>> >>> update Person set FirstName = 'Robert' where PersonID = 123 and FirstName = >>> 'Bob' and LastName = 'Roberts' >>> Finally, to make this change Is it as simple as unchecking the column and >>> redeploying my EOModel file? >>> >>> Thanks! >>> Jeff >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected] >> <mailto:[email protected]>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/prabier%40icloud.com >> <https://lists.apple.com/mailman/options/webobjects-dev/prabier%40icloud.com> >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/jeffschmitz%40icloud.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
