My intention was not to replace the Java code by SQL. You could just update 
your column with:
https://jenkins.wocommunity.org/job/WonderIntegration/javadoc/er/extensions/eof/ERXEOAccessUtilities.html#updateRowsDescribedByQualifier(com.webobjects.eocontrol.EOEditingContext,
 java.lang.String, com.webobjects.eocontrol.EOQualifier, 
com.webobjects.foundation.NSDictionary)

But if you find your way, that's great. 

Philippe 
---------------------
http://twitter.com/prabier

Sent from my iPhone

> On 18 Mar 2016, at 23:12, Jeff Schmitz <[email protected]> wrote:
> 
> 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]> 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]> 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]> on 
>>>> behalf of Jeff Schmitz <[email protected]>
>>>> Date: Thursday, March 17, 2016 at 5:20 PM
>>>> To: WebObjects Development <[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])
>>> Help/Unsubscribe/Update your Subscription:
>>> 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]

Reply via email to