Breaking changes

Breaking changes may require changes in configuration, apps, or native module code after an ApiOmat upgrade to ensure system stability.

• Object-based DeltaSync:

  • When a client makes a request to a collection with a query like "a < 10" and receives 2 objects (a=8, a=9), he can send these objects' IDs and lastModifiedAt in the next collection query with "a < 10".

  • Until now, the server responded with a delta-deleted header that included the IDs of those objects that were either deleted or changed in a way that they're not part of the result anymore (e.g. changed to a=11).

  • But without differentiation between these two cases, clients didn't know whether to delete the objects from the local storage or not.

  • From now on, the server will respond with a delta-deleted header for deleted object IDs and a delta-removed header for objects that are just not part of the result anymore.

  • This change only applies to object-based DeltaSync. When using collection-based DeltaSync, there's no delta-removed header in the response at all and there are also no object IDs of objects that aren't part of the result anymore in the delta-deleted header.

  • Clients with old SDKs will still work, because the server will combine deleted and removed object IDs in the delta-deleted header when the x-apiomat-sdkversion header is < 2.5.5, leading to the old behavior.

  • New versions of most SDKs already take care of the separate response headers and the correct handling regarding the offline storage. The handling for the C# / Xamarin and Swift SDKs will be fixed in an upcoming version.

  • When using requests without SDK version header, you need to change the DeltaSync handling.

  • When using DeltaSync in Native Modules, no automatic SDK version check is done and you need to change the handling as well (e.g. start using r.setDeltaSyncRemovedList(...) etc.).

Remarkable changes

Remarkable changes do not affect system stability after ApiOMat upgrade, but may require changes in configuration, apps, or modules in the next development cycle.

• The Audit Log feature is now deactivated by default for new installations. To activate it follow the instructions in the note on the Audit Log page.

• Modules are now deployed in bottom-up order. If you have a Module A which uses Module B, then, while deploying Module A, the onDeploy-Method of Module B is called first and afterwards the one of Module A. In un-deploy process the methods are called top-down. When undeploying Module A, the onUndeploy method of Module A is called first and then the one of Module B. Note that the invocation of these methods are done only in the context of a specific module (the two onDeploy method calls for the deployment of module A is independent from the onDeploy method call of module B)

All changes in the current and previous versions can be found at the root page.

All deprecations and their removal date can be found at Deprecations and Migration.

Changelog

13 issues