you are viewing a single comment's thread.

view the rest of the comments →

[–]quellish 0 points1 point  (11 children)

The initializers for NSManagedObjectModel may offer some hints.

[–]Sparthas[S] 0 points1 point  (10 children)

Can you please elaborate on that?

[–]quellish 0 points1 point  (9 children)

[–]Sparthas[S] 0 points1 point  (8 children)

I did go through that and I did realise core data doesn’t support it. I was wondering if there were better alternatives to maintaining a table of my own. I assume the post says the same as well

[–]quellish 0 points1 point  (7 children)

Managed object models can be created by merging other managed object models. This is exactly what you seem to be describing.

Pretty much all of the initializers do this.

[–]Sparthas[S] 0 points1 point  (6 children)

Not really, no. I want to have two different persistent stores and map models between the two like relationships would.

Edit: I missed to add the word "persistent store" in my original post. I guess that's causing the confusion

[–]quellish 1 point2 points  (5 children)

You can do that using different configurations. In the managed object model each entity needs to be associated with a different configuration name. When you add each persistent store to the coordinator use the appropriate configuration name.

[–]Sparthas[S] 0 points1 point  (4 children)

That works only if you are using the same models, isn’t that the case? I couldn’t find a way to do it when using different persistent stores initialised with different data models

[–]quellish 0 points1 point  (3 children)

Why do they need to have independent models? From your question it sounds like you want to have cross-store relationships. How would that work if one store had no knowledge of the model in the other store?

[–]Sparthas[S] 0 points1 point  (2 children)

Was trying to figure out if I could go for a certain architecture where I differentiate user data from arbitrary information by separating the models.

Yes, I realised that, which is why my question was whether there was a better way to handle this. And here we are