« Changelog History


Realm v10.32.0 Release Notes

Release Date: 2022-10-10 // over 1 year ago

  • ✨ Enhancements

    • ➕ Add .recoverUnsyncedChanges (RLMClientResetModeRecoverUnsyncedChanges) and .recoverOrDiscardUnsyncedChanges (RLMClientResetModeRecoverOrDiscardUnsyncedChanges) behaviors to ClientResetMode (RLMClientResetMode).
      • The newly added recover modes function by downloading a realm which reflects the latest state of the server after a client reset. A recovery process is run locally in an attempt to integrate the server state with any local changes from before the client reset occurred. The changes are integrated with the following rules:
      • Objects created locally that were not synced before client reset, will be integrated.
      • If an object has been deleted on the server, but was modified on the client, the delete takes precedence and the update is discarded.
      • If an object was deleted on the client, but not the server, then the client delete instruction is applied.
      • In the case of conflicting updates to the same field, the client update is applied.
      • The client reset process will fallback to ClientResetMode.discardUnsyncedChanges if the recovery process fails in .recoverOrDiscardUnsyncedChanges.
      • The client reset process will fallback to ClientResetMode.manual if the recovery process fails in .recoverUnsyncedChanges.
      • The two new swift recovery modes support client reset callbacks: .recoverUnsyncedChanges(beforeReset: ((Realm) -> Void)? = nil, afterReset: ((Realm, Realm) -> Void)? = nil).
      • The two new Obj-C recovery modes support client reset callbacks in notifyBeforeReset and notifyAfterResetfor both [RLMUser configurationWithPartitionValue] and [RLMUser flexibleSyncConfigurationWithClientResetMode] For more detail on client reset callbacks, see ClientResetMode, RLMClientResetBeforeBlock, RLMClientResetAfterBlock, and the 10.25.0 changelog entry.
    • ➕ Add two new additional interfaces to define a manual client reset handler:
      • Add a manual callback handler to ClientResetMode.manual -> ClientResetMode.manual(ErrorReportingBlock? = nil).
      • Add the RLMSyncConfiguration.manualClientResetHandler property (type RLMSyncErrorReportingBlock).
      • These error reporting blocks are invoked in the event of a RLMSyncErrorClientResetError.
      • See ErrorReportingBlock (RLMSyncErrorReportingBlock), and ClientResetInfo for more detail.
      • Previously, manual client resets were handled only through the SyncManager.ErrorHandler. You have the option, but not the requirement, to define manual reset handler in these interfaces. Otherwise, the SyncManager.ErrorHandler is still invoked during the manual client reset process.
      • These new interfaces are only invoked during a RLMSyncErrorClientResetError. All other sync errors are still handled in the SyncManager.ErrorHandler.
      • See 'Breaking Changes' for information how these interfaces interact with an already existing SyncManager.ErrorHandler.

    💥 Breaking Changes

    • 0️⃣ The default clientResetMode (RLMClientResetMode) is switched from .manual (RLMClientResetModeManual) to .recoverUnsyncedChanges (RLMClientResetModeRecoverUnsyncedChanges).
      • If you are currently using .manual and continue to do so, the only change you must explicitly make is designating manual mode in your Realm.Configuration.SyncConfigurations, since they will now default to .recoverUnsyncedChanges.
      • You may choose to define your manual client reset handler in the newly introduced manual(ErrorReportingBlock? = nil) or RLMSyncConfiguration.manualClientResetHandler, but this is not required. The SyncManager.errorHandler will still be invoked during a client reset if no callback is passed into these new interfaces.

    🗄 Deprecations

    • 🗄 ClientResetMode.discardLocal is deprecated in favor of ClientResetMode.discardUnsyncedChanges. The reasoning is that the name better reflects the effect of this reset mode. There is no actual difference in behavior.

    Compatibility

    • Realm Studio: 11.0.0 or later.
    • 🚀 APIs are backwards compatible with all previous releases in the 10.x.y series.
    • 🚀 Carthage release for Swift is built with Xcode 14.0.1.
    • CocoaPods: 1.10 or later.
    • Xcode: 13.1-14.1.