Realm-cocoa: Creating separate realm files contain objects declared in either instance, causes migration issues

[mowens]

Hoping to get some insight here. Currently I am writing an application that keeps 2 separate realm files, lets call them a.realm and b.realm. Each of these are managing there own set of unique objects, lets say:

Managed by a.realm

• FooObject
• BarObject

Managed by b.realm

• BazObject

The problem is regardless that these files are separate and managed by separate Realm.Configuration's, when looking at a.realm and b.realm then both have tables for all 3 objects, however the database files themselves only contain the entries for the objects they manage. This becomes a problem for migrations as if I need to migrate BazObject I need to apply a migration to both a.realm and b.realm when I only should have to apply this to b.realm.

Now a "fix" would be to just apply the migration to both Realm.Configuration's and be done with it, however each of these realm db files are managed in separate frameworks, therefore having to maintain a schema migration at the top level that leverages these database files seems in correct to me. What I'm really concerned about is how both of the files have the tables for objects they don't manage?

[tgoyne]

You can specify the set of classes which are stored in a Realm with the objectTypes property of the Realm.Configuration object used to open the Realm, and then only those classes will have tables created and be checked for schema matches. For example, you can do:

let config1 = Realm.Configuration(path: "a.realm", schemaVersion: 1, objectTypes: [FooObject.self, BarObject.self])
let realm1 = try! Realm(configuration: config2)

let config2 = Realm.Configuration(path: "b.realm", schemaVersion: 2, objectTypes: [BazObject.self)
let realm2 = try! Realm(configuration: config2)

Each Realm will then be able to have separate schema versions and migration blocks. Do note that both the frameworks and the main app (if it also uses Realm) will need to explicitly list which types to include, and you'll still need to ensure that there's no name collisions, but otherwise the frameworks' use of Realm should be entirely independent.

[mowens]

Doh! Totally missed that configuration parameter. Thanks! @tgoyne

[rajdas1]

This is so helpful. I faced this and couldn't understand the source of the issue. Even after migrating the 'concerned' realm, other's threw the same error. Now I know all of them were 'concerned' realms since no object types were specified. Thanks!

A note to reflect this should be added in the Realm docs IMO. It's an easy to reach scenario since objectTypes is a default parameter (defaults to nil) while creating a configuration.