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, RLMArrays, and RLMResults 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

Discussion

The default Realm is used by the RLMObject 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.

Discussion

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

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

Discussion

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, RLMArrays, and RLMResults that refer to objects persisted in a Realm have a strong reference to the relevant RLMRealm, as do RLMNotifcationTokens.

Discussion

This method is called automatically when opening a Realm for the first time and does not need to be called explicitly. You can choose to call this method to control exactly when and how migrations are performed.

Discussion

As migrateRealmAtPath:, but for encrypted realms.

Discussion

The on-disk storage for encrypted Realms are encrypted using AES256+HMAC-SHA2, but otherwise they behave like normal persisted Realms.

Encrypted Realms currently cannot be opened while lldb is attached to the process since lldb often hangs in this situation. See issue #1625 for further discussion. Attempting to open an encrypted Realm with lldb attached will result in an EXC_BAD_ACCESS. Running your application with REALM_DISABLE_ENCRYPTION=YES set in your environment will result in Realm treating requests to open an encrypted Realm as requesting an unencrypted Realm.

Discussion

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

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 provide 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 ensure uniqueness if a primary key property is added to an existing object.

You should call this method before accessing any RLMRealm instances which require migration. After registering your migration block Realm will call your block automatically as needed.

Discussion

This can be used as an alternative to explicitly passing the key to realmWithPath:key:readOnly:error: each time a Realm instance is needed. The encryption key will be used any time a Realm is opened with realmWithPath: or defaultRealm.

If you do not want Realm to hold on to your encryption keys any longer than needed, then use realmWithPath:encryptionKey:readOnly:error: rather than this method.

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 the object or any linked objects already belong to a different Realm an exception will be thrown. Use [RLMObject createInRealm:withObject] to insert a copy of a persisted object into a different Realm.

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

Discussion

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

Discussion

As with addObject:, the object cannot already be persisted in a different Realm. Use [RLMObject createOrUpdateInRealm:withValue:] to copy values to a different Realm.

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

This rolls back all objects in the Realm to the state they were in at the beginning of the write transaction, and then ends the transaction.

This restores the data for deleted objects, but does not re-validated deleted accessor objects. Any RLMObjects which were added to the Realm will be invalidated rather than switching back to standalone objects. Given the following code:

 ObjectType *oldObject = [[ObjectType objectsWhere:@"..."] firstObject];
 ObjectType *newObject = [[ObjectType alloc] init];

 [realm beginWriteTransaction];
 [realm addObject:newObject];
 [realm deleteObject:oldObject];
 [realm cancelWriteTransaction];

Both oldObject and newObject will return YES for isInvalidated, but re-running the query which provided oldObject will once again return the valid object.

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

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.

Discussion

Cannot be called from a write transaction.

Compaction will not occur if other RLMRealm instances exist.

While compaction is in progress, attempts by other threads or processes to open the database will wait.

Be warned that resource requirements for compaction is proportional to the amount of live data in the database.

Compaction works by writing the database contents to a temporary database file and then replacing the database with the temporary one. The name of the temporary file is formed by appending .tmp_compaction_space to the name of the database.

Discussion

An RLMRealm holds a read lock on the version of the data accessed by it, so that changes made to the Realm on different threads do not modify or delete the data seen by this RLMRealm. Calling this method releases the read lock, allowing the space used on disk to be reused by later write transactions rather than growing the file. This method should be called before performing long blocking operations on a background thread on which you previously read data from the Realm which you no longer need.

All RLMObject, RLMResults and RLMArray instances obtained from this RLMRealm on the current thread are invalidated, and can not longer be used. The RLMRealm itself remains valid, and a new read transaction is implicitly begun the next time data is read from the Realm.

Calling this method multiple times in a row without reading any data from the Realm, or before ever reading any data from the Realm is a no-op. This method cannot be called on a read-only Realm.

Discussion

The destination file cannot already exist.

Note that if this is called from within a write transaction it writes the current data, and not data when the last write transaction was committed.

Discussion

The destination file cannot already exist.

Note that if this is called from within a write transaction it writes the current data, and not data when the last write transaction was committed.