Ревизии для IVersionedEntity

В API V9Preview3 изменена работа ревизий для IVersionedEntity.

Ранее ревизия IVersionedEntity.Revision была сквозная между терминалами одной группы. Ревизия назначалась на главной кассе и передавалась ведомым терминалам. В силу этого, для корректной работы синхронизации доступа к данным, плагины, использующие функции редактирования данных, предпочтительно было устанавливать на главную кассу. При установке на другие терминалы, в некоторых сценариях плагин мог разово получать отказы в применении изменений.

Теперь каждый терминал фронта ведет свою ревизию объектов. Это означает, что необоснованные отказы в применении изменений по причине “архитектурной особенности” фронта устранены. Ревизию нельзя использовать как критерий сравнения объектов на разных терминалах.

При каждом изменении объекта назначается новая ревизия, ревизия строго и монотонно растет. Однако, монотонный рост ревизии гарантируется только в пределах одной и той же базы данных терминала фронта. Объектам может быть переназначена ревизия, в случае если произошло пересоздание фронтовой базы данных. Например, это может произойти при смене главного терминала. В связи с этим был добавлен новый метод GetHostDatabaseId, который возвращает идентификатор фронтовой базы данных. При пересоздании фронтовой БД, ей назначается новый идентификатор. Идентификатор базы данных не может меняться в процессе работы фронта, поэтому достаточно проверить его один раз при запуске. Если при очередном запуске идентификатор базы данных поменялся, следует считывать данные, начиная с нулевой ревизии: GetChangedOrders,GetChangedDeliveryOrders,GetChangedKitchenOrders,GetChangedReserves.

В SamplePlugin был добавлен пример отслеживания сброса ревизий.