On Sep 19, 2010, at 5: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).
I would not worry until I got to 100,000. If you see issues in performance testing (or actual usage), THEN worry. > 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. If you will be running multiple instances, then you need to do something to handle data freshness issues. Chuck > --- On Sun, 9/19/10, David Avendasora <[email protected]> wrote: > >> From: David Avendasora <[email protected]> >> Subject: Re: EOEditingContext help >> To: "Theodore Petrosky" <[email protected]> >> Cc: [email protected] >> 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 protected]) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.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: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
