Hi Ted,

The only change I would make is to use ETime.IS_ACCEPTED_KEY instead of 
"isAccepted" in etimesArray.takeValueForKey(true, "isAccepted");

They are functionally identical, but if for some reason the attribute name 
changes from isAccepted to something else, changing it will cause a compiler 
error instead of a runtime error, so you are much safer when refactoring in the 
future.

Dave


On Sep 19, 2010, at 8:57 AM, Theodore Petrosky wrote:

> so here is what I came up with.
> 
> jobListArray = Job.fetchJobs(theProject().editingContext(), 
> Job.PROJECT.eq(theProject()), null);   
> 
> etimesArray = ETime.fetchETimes(theProject().editingContext(), 
>                               ETime.JOB.in(jobListArray), 
>                               null);
> 
> etimesArray.takeValueForKey(true, "isAccepted");
> 
> I have the project that has jobs that has timeobjects. can you think of an 
> easier way to update these records?
> 
> Ted
> 
> --- On Sun, 9/19/10, David Avendasora <webobje...@avendasora.com> wrote:
> 
>> From: David Avendasora <webobje...@avendasora.com>
>> Subject: Re: EOEditingContext help
>> To: "Theodore Petrosky" <tedp...@yahoo.com>
>> Cc: webobjects-dev@lists.apple.com
>> Date: Sunday, September 19, 2010, 8:48 AM
>> While you _could_ easily do this in
>> the DB, as you mentioned, it is behind EOF's back, which is
>> going to cause you all sorts of extra work to make sure
>> you've got fresh objects and such.
>> 
>> Trust in EOF. Let it do all the work. As a general rule,
>> only start writing SQL if all EOF optimizations have failed
>> get the performance you _need_ and the function is still
>> taking too long. 1000 objects will likely update in less
>> than a second anyway.
>> 
>> Dave
>> 
>> On Sep 19, 2010, at 8:20 AM, Theodore Petrosky wrote:
>> 
>>> Users are adding time/work objects. (I worked on job
>> number 10 for .25 hour and here is what I did.)
>>> 
>>> the finance department runs a report that gets all
>> these work objects and when they are happy they mark them as
>> 'Accepted'. This is what I am capturing.
>>> 
>>> I need to mark 1000 objects as accepted. I could get
>> an array of all the objects, mark them as accepted and save
>> the EC.
>>> 
>>> or just tell the database update all time/work record
>> of job number 10 to accepted. But of course this is behind
>> the back of my App.
>>> 
>>> I don't think there will be more than 1 to 2 thousand
>> objects (50 users with 20 hits = 1000 objects).
>>> 
>>> At issue is, once the object is marked as accepted,
>> the users can not edit the object. So if a user selects an
>> object to edit, the save junction is disabled if the time
>> object is marked as accepted.
>>> 
>>> I think I will try what you recommended and see if
>> there is a reason to care about the procedure.
>>> 
>>> Ted
>>> 
>>> 
>>> --- On Sun, 9/19/10, David Avendasora <webobje...@avendasora.com>
>> wrote:
>>> 
>>>> From: David Avendasora <webobje...@avendasora.com>
>>>> Subject: Re: EOEditingContext help
>>>> To: "Theodore Petrosky" <tedp...@yahoo.com>
>>>> Cc: webobjects-dev@lists.apple.com
>>>> Date: Sunday, September 19, 2010, 7:01 AM
>>>> Hi Ted,
>>>> 
>>>> Can you define "whole bunch" are we talking
>> thousands,
>>>> millions? I follow the mantra of "First make it
>> work, then
>>>> worry about optimizing it if it is to slow."
>>>> 
>>>> If you are updating the same attribute on all the
>> objects,
>>>> you can simply use key-value coding.
>>>> 
>>>> myArray.takeValueForKey(newValue,
>> Entity.ATTRIBUTE_KEY);
>>>> 
>>>> Also, how are you saving? Are you saving each
>> object, or
>>>> saving the EditingContext?
>>>> 
>>>> Dave
>>>> 
>>>> 
>>>> On Sep 18, 2010, at 11:38 PM, Theodore Petrosky
>> wrote:
>>>> 
>>>>> I have to update a whole bunch of objects.
>> Method 1
>>>> says make a list of the objects, make the changes
>> and
>>>> saveChanges(). Seems really inefficient. If there
>> were only
>>>> 50 objects I would probably do that. So I created
>> a
>>>> procedure on backend. Basically, an update of all
>> records
>>>> that match a job number.
>>>>> 
>>>>> Of course this is making a change behind the
>> back of
>>>> my WO App. and someone may be looking at this
>> data.
>>>>> 
>>>>> So what are my choices? go back to method 1.
>> Looping
>>>> through 500 records, then saving changes? Or is
>> there a way
>>>> to selectively invalidate these objects to force
>> any other
>>>> users to get fresh data?
>>>>> 
>>>>> Ted
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> _______________________________________________
>>>>> Do not post admin requests to the list. They
>> will be
>>>> ignored.
>>>>> Webobjects-dev mailing list   
>>   (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>> 
>>>>> This email sent to webobje...@avendasora.com
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to