Revisions for IVersionedEntity

In the API V9Preview3, the operation of revisions for IVersionedEntity has been changed.

Previously, the revision IVersionedEntity.Revision was continuous across terminals within the same group. The revision was assigned at the main cash register and transmitted to subordinate terminals. Because of this, for proper synchronization of data access, plugins using data editing functions were preferably installed on the main cash register. When installed on other terminals, in some scenarios, the plugin could occasionally receive refusals to apply changes.

Now, each front terminal maintains its own revision of objects. This means that unjustified refusals to apply changes due to “architectural features” of the front have been eliminated. The revision cannot be used as a criterion for comparing objects on different terminals.

With each change to an object, a new revision is assigned, and the revision strictly and monotonically increases. However, the monotonous growth of the revision is guaranteed only within the same database of the front terminal. Revisions may be reassigned to objects if the front database is recreated. For example, this can occur when the main terminal changes. In this regard, a new method GetHostDatabaseId has been added, which returns the identifier of the front database. When the front database is recreated, it is assigned a new identifier. The database identifier cannot change during the operation of the front, so it is sufficient to check it once at startup. If the database identifier has changed upon the next startup, data should be read starting from the zero revision: GetChangedOrders,GetChangedDeliveryOrders,GetChangedKitchenOrders,GetChangedReserves.

In the SamplePlugin, an example of tracking revision resets has been added.