Realm Configuration Sanity Check

[TimOliver]

When modified via the Configuration object, Realm instances can represent one of three different Realm types.

• Local Realms
• In-memory Realms
• Synchronized Realms

These states are mutually exclusive and Realms created in one context can't be converted to another. They also each have specific properties in the Configuration object governing how the type of the Realm is controlled:

• fileURL for local Realms
• inMemoryIdentifier for in-memory Realms
• syncConfiguration for synchronized Realms

When creating Realms for one context, it doesn't make sense to also modify the properties for the other contexts (eg setting an inMemoryIdentifier value for a synchronized Realm).

At the moment, Realm will accept a Configuration containing all of these properties and will set up a Realm instance in the same reliable internal logic, but to avoid user confusion, I'm wondering if it's worth adding a console warning to let users know that they shouldn't be setting these properties in specific circumstances.

Are there any opinions on this?

Goals

Let Realm be more vocal and concise about what it's going to do with a Realm Configuration object when properties representing conflicting Realm types are modified.

Expected Results

If modifying conflicting properties like syncConfiguration and inMemoryIdentifier, Realm to log a warning in the console letting the developer know that one property will be ignored, and it shouldn't be set.

Actual Results

Absolutely nothing.

[nirinchev]

I feel this would be better addressed by creating separate classes for the different configuration types that expose only properties relevant to the chosen type. This way, it will be clear at compile time which combinations are supported and which are not.

[jpsim]

Actually, we do have runtime checks to avoid setting say deleteRealmIfMigrationNeeded when readOnly is set or shouldCompactOnLaunch when readOnly or syncConfiguration are set, vice-versa.

If you can think of other incompatible combinations that aren't being validated, please let us know.

I do think your idea of having mutually exclusive configuration options be reflected at the API level is a good one, avoiding these kinds of issues at compile-time rather than run-time, so we should still keep this open.

[austinzheng]

@jpsim Is this something we're interested in for 3.0?

[jpsim]

It would definitely make sense to encapsulate the mutually exclusive configuration members in an enum:

enum RealmType {
  case file(url: URL)
  case inMemory(identifier: String)
  case synchronized(user: SyncUser, url: URL, enableSSLValidation: Bool)
}

[austinzheng]

Sweet. Should we do something similar for ObjC (with subclasses)?

[jpsim]

Not sure it can elegantly be modeled in ObjC. If you can think of something, might be worth presenting a design at tomorrow's cocoa call.

[austinzheng]

We won't be doing this for Realm 3, unfortunately.

[dfg-1310]

Due to security concerns, I do not want to save the realm database on the hard disk so I added the inMemoryIdentifier in Realm Configuration. Realm database file is not creating for the new build.

But I have an issue with the existing build, We still have an existing realm database device hard disk so My question is How I can delete the existing realm database from the app?