views:

31

answers:

1

I'm coming from SQL and n-tiered systems and trying to work through how to use Core Data effectively for this usage:

  • insert new managed object - I'm having no problem there
  • delete existing managed object - I'm having no problem there
  • editing existing managed object - problem.

The problem is how do i identify that object as unique and find it within the 0 to 100 million records I might have? I know you can use:

[managedObject objectID]

against the instanced managed object context to get the universally unique identifier for a managed object that is persisted to the data store. But what if I don't have that to start with? How are you getting to those unique objects.

Is querying against enough attributes to achieve unique results the way or is there something I'm missing?

Any help appreciated // :)

+1  A: 

You shouldn't think of Core Data in SQL terms. In that way lays madness. Entities are not tables or records, attributes are not fields. Relationships are not linking tables. Core Data is an object graph management system. It maintains the relationships between live objects with contain both data and behaviors. Any SQL that might or might not be involved in any particular app occurs behind the scenes within Core Data itself and has no influence on the app the design or coding.

The major means of finding unique of objects is through their relationships. The more complex the relationships the more narrowly the relationships define particular objects. Suppose you have a graph with three entities linked thusly: Department<-->>Employee<<-->Specialization. Suppose you want to find all the departments who have an engineer named "Bob." You would do a fetch of Department entities using a predicate like:

"employees.firstName=="Bob" AND employees.specialization.type=="Engineer"

This would return a small number of Department objects. If you wanted to find the employees themselves, you would then use a predicate to filter each returned department's employees relationship for the specific employee attributes you wanted to find.

You can save permanent objectIDs as URIs stored in NSURLs and find specific objects but that is usually only done to link objects that can't form relationships because they are saved in separate persistent stores.

The major way to locate objects is (1) find a subset of objects using a fetch (2) walk those objects relationships to find related objects. Since Core Data is built around relationships between objects, a well structured entity graph can often uniquely identify objects by their relationships alone.

TechZen