small medium large xlarge

Back to: All Forums  Core Data
Generic-user-small
02 Oct 2009, 03:32
Matt Watson (4 posts)

Hi there,

I’ve been struggling to find an answer to a problem I’ve currently got to solve.

I’ve developed an iphone app (and a mac app for data entry) that both use the same datamodel.

I can create data in the mac app, save it as a sqlite file, and load it into my iphone app. That works fine.

The sqlite database contains mostly “read only” data that will be updated - new records, fix spelling mistakes that kind of thing - with each new app release. So the “model” won’t be changing, only the “data”.

The end user will also be able to select records from the “read only” data and add them as “favourites” together with some basic details.

So for the first release everything will be easy. However I haven’t figured out how to handle the “subsequent” releases yet.

What would be your “best practice” suggestion to solve this?

Obviously I won’t be able to simply replace the database entirely - with each update - due to the users “favourites”.

Thanks in advance, Matt

PS: It could be worth mentioning a solution to this kind of problem in your book perhaps?

Avatarsmall_pragsmall
06 Oct 2009, 15:37
Marcus S. Zarra (284 posts)

I would store the read only data in one model and the write data in a second model and then load them both into the same core data stack by merging the models and adding each persistent store to the persistent store coordinator. This would allow you to change the read only data whenever you wanted without impacting the write data.

Generic-user-small
09 Oct 2009, 02:03
Matt Watson (4 posts)

Thanks for your reply.

When you refer to the “two” models (read only, writeble) do you mean two xcdatamodel files? or do you mean two sqlite files?

If there are “two” sqlite file would you have only certain tables in each of the files? Can Core Data sync the two?

Avatarsmall_pragsmall
27 Oct 2009, 00:08
Marcus S. Zarra (284 posts)

You would have two models and two sqlite files underneath. You can add both of them to the same persistent store coordinator and from the managed object context’s PoV there is one set of data. When you write to the writable tables, Core Data will do the correct thing and save the data to the writable database.

Generic-user-small
08 Nov 2009, 20:55
Matt Watson (4 posts)

Hi Marcus,

Thanks again for your reply.

My only final question is this:

How do I create a relationship between entities that spans both models (read, write) in Xcode?

Or is this something that I’ll need to do manually i.e. maintain my own set of quasi primary heys and force lookups in code?

Thanks in advance, Matt

Avatarsmall_pragsmall
08 Nov 2009, 21:14
Marcus S. Zarra (284 posts)

Relationships across the boundaries of the two contexts can be tricky. You could reference the uniqueID of the object in the read only store from the read-write store but that uniqueID can change when a migration occurs.

If possible, I would recommend representing the relationship as a fetch request so that you retrieve it into a transient object each time the application is run and the relationship is requested.

Generic-user-small
11 Nov 2009, 03:06
Matt Watson (4 posts)

I’d like to follow your suggestion but I’m not 100% sure how to do this.

Do you know of (or have) any sample code that might illustrate this?

Thanks, Matt

Avatarsmall_pragsmall
17 Nov 2009, 16:56
Marcus S. Zarra (284 posts)

Unfortunately nothing in a public code base that I can share.

Each NSManagedObject has a -objectID which returns NSManagedObjectID. That objectID can be turned into a URI with a call to -uriRepresentation. That can then be turned into an NSString with a call to -absoluteString.

All of that can be reversed so that the referenced object can be retrieved from the stored string representation.

That is option one. Option two requires a more indepth knowledge about your data model as it is only possible if you can figure out how to link the two based on a NSPredicate.

You must be logged in to comment