Multiple Core Data stores like documents?

Background
==============================
I'm building a small application currently targeting macOS 10.15, but might add iPadOS support in the future. This application is an API client for a server from another company. I have no control over the format of the returned data.

This server stores and processes simple data objects, most of which would be created by the user. Each object is canonically identified by a UUID. A single server can never have two items with the same UUID, so it's great for uniquely tracking objects within a single instance of the server.

The problem is a single organization may have as many as ~30 instances of this server. While they mostly store data the user specifies, they come with around 8000 pre-defined items. The pre-defined items have static UUIDs, which are the same from one instance to another. These pre-defined items are mutable, so a single UUID may not represent the same object configuration from one server instance to another.

The server has a concept of sessions and the API exposes a way to track what changed between a previous session and the current session in its database. I would like to use Core Data to cache the objects on the user workstation so I don't have to download everything every time I connect.

Right now, I am building a class which represents the connection to a server. Eventually, I expect to be able to open multiple instances of the object, and I would like them to not step on each others' toes.



My Questions
==============================
I'm thinking about building the NSPersistentContainer as an instance variable inside my class, to be initialized once the API connection is successful. Does that sound rational, or should I track the servers as entities in a single NSPersistentContainer for the whole application?

If I use multiple NSPersistentContainers as above, should I use a different name per instance?

Do I need to handle the NSPersistentStoreDescription URL myself to ensure uniqueness, or is that generated automatically somehow? If it's automatic, how is it generated?

Accepted Reply

Each persistent container maps to a separate database file. This is handy for situations where they have different iOS security classes, or other file-wide behaviors.

In your case, you have different subgraphs for each "server" for each "organization". Personally I think I'd just model this data in a single file exactly that way. You can namespace the UUIDs to avoid your conflict issue. Core Data supports multi-column unique constraints.

Replies

Forgot to add: I don't think NSPersistentDocument is directly relevant, as the data doesn't have any significance without the server. For example, the server does not let you build a new object with a UUID you specify, it assigns a UUID to new objects. There is no reason for anything to touch the document except when connected to the server. No reason to copy them from workstation to workstation, or to back them up.

Right now, I'm only interested in the ability to cache data so I don't have to download everything on every launch. It seems to me the document stuff is just unnecessary overhead, but maybe I'm missing something. Maybe the best way to do this is persistent documents automatically named and saved in ~/Library? But that seems like what multiple persistent containers would do.

That is what led me to ask here if multiple separate persistent containers might work.
Each persistent container maps to a separate database file. This is handy for situations where they have different iOS security classes, or other file-wide behaviors.

In your case, you have different subgraphs for each "server" for each "organization". Personally I think I'd just model this data in a single file exactly that way. You can namespace the UUIDs to avoid your conflict issue. Core Data supports multi-column unique constraints.
I knew about multi-column constraints, but I was thinking in terms of codable structs containing only the properties handed to me by the server. Now that you've mentioned namespaces, it seems obvious the solution is to just add my own property in the initializer which specifies which server the object is from, and use that in combination with the UUID to ensure uniqueness.

Thanks for the help!