Cross-Store weak relationship with Fetched Properties?

Question

I would like to separate my reference data from my user data in my Core Data model to simplify future updates of my app (and because, I plan to store the database on the cloud and there is no need to store reference data on the cloud as this is part of my application). Therefore, I've been looking for a while for a way to code a cross-store relationship using fetched properties. I have not found any example implementations of this.

I have a Core Data model using 2 configurations :

• data model config 1 : UserData (entities relative to user)

• data model config 2 : ReferenceData (entities relative to application itself)

I set up 2 different SQLite persistent stores for both config.

• UserData config (and store) contains entity "User"

• ReferenceData config (and store) contains entities "Type" and "Item".

I would like to create two single-way weak relationships as below :

• A "User" has a unique "Type"

• A "User" has many "Items"

Here are my questions :

• How do I set up my properties?

• Do I need 2 properties for each relation (one for storing Unique ID and another to access my fetched results)?

• Could this weak relationship be ordered?

• Could someone give me an example implementation of this?

As a follow-on to Marcus' answer:

Looking through the forums and docs, I read that I should use the URI Representation of my entity instance instead of objectID. What is the reason behind this?

// Get the URI of my object to reference 
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];

Next, I wonder, how do I store my object B URI (NSURL) in my parent object A as a weak relationship? What attribute type should I use? How do I convert this? I heard about archive... ?

Then, later I should retrieve the managed object the same way (by unconvert/unarchive the URIRepresentation) and get Object from URI

// Get the Object ID from the URI 
NSManagedObjectID* idObjectB = [storeCoordinator managedObjectIDForURIRepresentation:[[myManagedObject objectID] URIRepresentation]];

// Get the Managed Object for the idOjectB ...

And last but not least, shouId I declare two properties in my entity A, one for persisting of URI needs and another for retrieving direclty object B?

NSURL * uriObjectB [objectA uriObjectB];

ObjectB * myObjectB = [objectA objectB];

As you can read, I really miss some simple example to implement thes weak relationships ! I would really appreciate some help.

Answer 1

Splitting the data is the right answer by far. Reference data should not be synced with the cloud, especially since iCloud has soft caps on what it will allow an application to sync and store in documents.

To create soft references across to stores (they do not need to be SQLite but it is a good idea for general app performance) you will need to have some kind of unique key that can be referenced from the other side; a good old fashioned foreign key.

From there you can create a fetched property in the model to reference the entity.

While this relationship cannot be ordered directly you can create order via a sort index or if it has a logical sort then you can sort it once you retrieve the data (I use convenience methods for this that return a sorted array instead of a set).

I can build up an example but you really are on the right track. The only fun part is migration. When you detect a migration situation you will need to migrate each store independently before you build up your core data stack. It sounds tricky but it really is not that hard to accomplish.

Example

Imagine you have a UserBar entity in the user store and a RefBar entity in the reference store. The RefBar will then have a fetchedProperty "relationship" with a UserBar thereby creating a ToOne relationship.

UserBar
----------
refBarID : NSInteger

RefBar
--------
identifier : NSInteger

You can then create a fetched property on the RefBar entity in the modeler with a predicate of:

$FETCHED_PROPERTY.refBarID == identifier

Lets name that predicate "userBarFetched"

Now that will return an array so we want to add a convenience method to the RefBar

@class UserBar;

@interface RefBar : NSManagedObject

- (UserBar*)userBar;

@end

@implementation RefBar

- (UserBar*)userBar
{
    NSArray *fetched = [self valueForKey:@"userBarFetched"];
    return [fetched lastObject];
}

@end

To create a ToMany is the same except your convenience method would return an array and you would sort the array before returning it.

As Heath Borders mentioned, it is possible to add a sort to the NSFetchedProperty if you want but you must do it in code. Personally I have always found it wasteful and don't use that feature. It might be more useful if I could set the sort in the modeler.

Using the ObjectID

I do not recommend using the ObjectID or the URIRepresentation. The ObjectID (and therefore the URIRepresentation of that ObjectID) can and will change. Whenever you migrate a database that value will change. You are far better off creating a non-changing GUID.

The weak relationship

You only need a single value on the M side of the relationship and that stores the foreign identifier. In your object subclass you only need to implement accessors that retrieve the object (or objects).

Answer 2

I would go with just one store.

For storing stuff in the cloud, you will anyway have to serialize the data, either as JSON or SQL statements, or whatever scheme you prefer.

You will need a local copy of the data on the user's device, so he can access it quickly and offline. The cloud store can have only the user entity, while the local store (part of the app) can also have the reference entity.

I have a similar project with a huge reference store (20000 records) with geographic information, and user generated content ("posts"). I use a single store. When I ship the app, the "posts" entity is also defined but empty. When I update the data model I simply re-generate the whole reference store before shipping.

I see absolutely no reason to go for a cross store solution here.