Revisions for IVersionedEntity

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

Previously, the IVersionedEntity.Revision value was shared across all terminals within the same group. The revision was assigned on the main cash register and then distributed to the subordinate terminals. Because of this, for proper synchronization of data access, it was recommended to install plugins that use data editing functions on the main cash register. When installed on other terminals, the plugin could occasionally encounter failures in applying changes.

Now, each Syrve POS terminal maintains its own object revision. This means that unjustified change application failures caused by Syrve POS “architectural specifics” have been eliminated. The revision can no longer be used as a criterion for comparing objects across different terminals.

Each time an object is modified, a new revision is assigned. The revision increases strictly and monotonically. However, this monotonic growth is guaranteed only within the same Syrve POS terminal database. Objects may receive new revision values if the Syrve POS database is recreated - for example, when the main terminal is changed. To handle this, a new method has been introduced GetHostDatabaseId, which returns the identifier of the Syrve POS database. When the Syrve POS database is recreated, it is assigned a new identifier. Since the database identifier cannot change during the Syrve POS operation, it is sufficient to check it once at startup. If, at the next startup, the database identifier differs from the previous one, you should reload data starting from revision zero using GetChangedOrders, GetChangedDeliveryOrders, GetChangedKitchenOrders, GetChangedReserves.

An example of tracking revision resets has been added to the SamplePlugin.