You're thinking of Core Data as SQL. Big mistake.
Entities are not tables and instances are not records. Each instance is its own object so you do have to change them individually. Otherwise, there wouldn't be much point to using an object graph.
Edit01:
How then would
you handle the following UI problem:
You want to present a table of Person
entities ordered by "name." BUT ...
the user can re-order the Person
entities shown in this table AND you
want that persisted so that the
entities are now sorted by "name" +
"displayOrder" (or whatever you want
to call it). Where do you maintain the
value of "displayOrder" if not as an
attribute of the Person entity?
Oh, I see what your trying to do. You making it a lot harder than it has to be. Core Data handles this type of function easily.
Sort orders are not (usually, see below) facets of the data model but rather the view controller i.e. they're just temporary orders used to display data to the user in a meaningful manner. As such they are created on the fly as needed. In this case you would create a NSSortDescriptor/s to sort on the attribute keys you wish. Then set your fetch request to use those sort descriptors. Then your fetch would return an array with the elements in the desired order.
No fuss no muss.
If the user wants a different sort order just make a different group of sort descriptors. There is no reason to include the sort logic in the actual data model itself and there are many reasons not to do.
Separating the actual data from the display is very important in the Model-View-Controller design pattern on with all the iPhone API is based. You don't want to include display logic in the data model and you don't want to store data or have data manipulating logic in the display.
Edit02:
In my case users will need to be able
to come back to the application, view
the table and see the Person entities
in the order THEY put them. How else
can you do this except by having a
displayOrder attribute?
If you do want to save the order as user data then you do need to include it in the data model.
By coincidence, I just had such a need. Here's how I handled the problem for a small number of objects. These are the methods of NSMangedObject subclass. This works for several hundred lightweight objects.
If you have a large number of heavy weight objects (thousands) I suggest creating a lightweight entity to implement a linked list. Call it OrderEntity. It would have an index attribute, a relationship to the indexed entity, a relationship to the previous OrderEntity and a relationship to the next. (Using a lightweight entity prevents you from having to fault heavy objects which saves memory and makes everything faster. You only have to fault the indexed object when you need to display it.)
Then you use the standard linked list methods to insert, swap and move the items in the list. Then you call update on the moved objects and they call all subsequent OrderEntities to update their indexes.
It can be as simple as having a method that calls the next OrderEntity, passes the current objects index and tells the next to set its order to passedIndex+1. That is basically the exact function as the SQL statement you want to mimic (because of course the logic is the same.)
If you have to do this a lot, create a NSManagedObject subclass to handle the indexing and then have your indexed classes inherit from that.