Discussion

If set to YES (the default), changes made on other threads will be reflected in this Realm on the next cycle of the run loop after the changes are committed. If set to NO, you must manually call refresh on the Realm to update it to get the latest version.

Even with this enabled, you can still call refresh at any time to update the Realm before the automatic refresh would occur.

Notifications are sent when a write transaction is committed whether or not this is enabled.

Disabling this on an RLMRealm without any strong references to it will not have any effect, and it will switch back to YES the next time the RLMRealm object is created. This is normally irrelevant as it means that there is nothing to refresh (as persisted RLMObjects and RLMArrays have strong references to the containing RLMRealm), but it means that setting RLMRealm.defaultRealm.autorefresh = NO in application:didFinishLaunchingWithOptions: and only later storing Realm objects will not work.

Defaults to YES.

Discussion

The default Realm is used by the RLMObject and RLMArray class methods which do not take a RLMRealm parameter, but is otherwise not special. The default Realm is persisted as default.realm under the Documents directory of your Application on iOS, and in your application’s Application Support directory on OS X.

RLMRealm objects are cached internally by Realm, and calling this method multiple times on a single thread within a single iteration of the run loop will normally return the same RLMRealm object. If you specifically want to ensure a RLMRealm object is destroyed (for example, if you wish to open a Realm, check some property, and then possibly delete the Realm file and re-open it), place the code which uses the Realm within an @autoreleasepool {} and ensure you have no other references to it.

Discussion

~/Application Support/{bundle ID}/default.realm on OS X.

default.realm in your application’s documents directory on iOS.

Discussion

Before you can open an existing RLMRealm which has a different on-disk schema from the schema defined in your object interfaces, you must supply a migration block which converts from the disk schema to your current object schema. At the minimum your migration block must initialize any properties which were added to existing objects without defaults and return a new schema version which is higher than the version of the on-disk schema.

You should always call this method on startup if you have any migrations that may need to be run. Realm will not call your migration block if the schema of the file on disk matches your currently defined object schema. Calling this method after the defaultRealm has been created will throw an exception.

Discussion

Like migrateDefaultRealmWithBlock:, but for a Realm at a given path rather than the default Realm. This must be called before you first open a Realm at the given path, but you may open Realms at other paths first.

Discussion

RLMRealm objects are cached internally by Realm, and calling this method multiple times with the same path on a single thread within a single iteration of the run loop on will normally return the same RLMRealm object.

Discussion

Like realmWithPath, but with the ability to open read-only realms and get errors as a NSError out parameter rather than exceptions.

Discussion

The default Realm is persisted to disk unless this method is called.

Because in-memory Realms are not persisted, you must be sure to hold on to a reference to the RLMRealm object returned from this for as long as you want the data to last. Realm’s internal cache of RLMRealms will not keep the in-memory Realm alive across cycles of the run loop, so without a strong reference to the RLMRealm a new Realm will be created each time. Note that RLMObjects and RLMArrays that refer to objects persisted in a Realm have a strong reference to the relevant RLMRealm, as do RLMNotifcationTokens.

Discussion

The block has the following definition:

 typedef void(^RLMNotificationBlock)(NSString *notification, RLMRealm *realm);

It receives the following parameters:

• NSString *notification: The name of the incoming notification. See RLMRealmNotification for information on what notifications are sent.
• RLMRealm *realm: The realm for which this notification occurred

Discussion

Once added, this object can be retrieved using the objectsWhere: selectors on RLMRealm and on subclasses of RLMObject. When added, all linked (child) objects referenced by this object will also be added to the Realm if they are not already in it. If linked objects already belong to a different Realm an exception will be thrown.

The object to be added cannot have been previously deleted from a Realm (i.e. isDeletedFromRealm) must be false.

Discussion

This is the equivalent of addObject: except for an array of objects.

Discussion

This is the equivalent of addOrUpdateObject: except for an array of objects.

Discussion

Only one write transaction can be open at a time. Write transactions cannot be nested, and trying to begin a write transaction on a RLMRealm which is already in a write transaction with throw an exception. Calls to beginWriteTransaction from RLMRealm instances in other threads will block until the current write transaction completes.

Before beginning the write transaction, beginWriteTransaction updates the RLMRealm to the latest Realm version, as if refresh was called, and generates notifications if applicable. This has no effect if the RLMRealm was already up to date.

It is rarely a good idea to have write transactions span multiple cycles of the run loop, but if you do wish to do so you will need to ensure that the RLMRealm in the write transaction is kept alive until the write transaction is committed.

Discussion

After this is called the RLMRealm reverts back to being read-only.

Calling this when not in a write transaction will throw an exception.