Re: EOEditingContext help
Re: EOEditingContext help
- Subject: Re: EOEditingContext help
- From: David Avendasora <email@hidden>
- Date: Sun, 19 Sep 2010 11:36:55 -0400
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 <email@hidden> wrote:
>
>> From: David Avendasora <email@hidden>
>> Subject: Re: EOEditingContext help
>> To: "Theodore Petrosky" <email@hidden>
>> Cc: email@hidden
>> 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 <email@hidden>
>> wrote:
>>>
>>>> From: David Avendasora <email@hidden>
>>>> Subject: Re: EOEditingContext help
>>>> To: "Theodore Petrosky" <email@hidden>
>>>> Cc: email@hidden
>>>> 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
>> (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