DS ЧаВо¶

this is a set of notes for Russian development team that works on this task, not useful for system users and developer. Pls return to the distributed store for any information. Thank you.

• Table of contents
• DS ЧаВо
  • Где создаются экземпляры Environment?
  • Где (в каком классе) вызываются onUpdated и прочее?
  • Как слот узнает что его контракт изменился?
  • в каком классе исполняется смартконтракт (слотконтракт)?
  • как юзеру получить список всех своих сохраненных контрактов? по ключам? по hashId?
  • что храним в БД постгреса - юзерские контракты или слот-контракты? Или сущность слот-контракта собирается из набора данных из разных таблиц БД?
  • в БД у одного контракта есть множество подписок с expires_at. как считать общее время хранения?
  • что насчет ресинка хранилища? (например добавляем новую ноду в сеть)
  • может быть balance слота нужно сохранять вместе с таймстампом начала срока хранения?

Где создаются экземпляры Environment?¶

Каждая нода создает таблицу, в которой сохраняет environment, связывая его с origin контракта (SLOT-контракта).

Где (в каком классе) вызываются onUpdated и прочее?¶

В коде ноды, возможно, в процессоре, после того, как в леджер внесены все изменения в соответствии с новым статусом

Как слот узнает что его контракт изменился?¶

Слот подписывается на ContractStorageSubscription и если ему нужны эти ответы, то он подключает там #receiveEvents(true). В этом случае система дернет NContract#onContractStorageSubscriptionEvent соответственно когда новая ревизия tracked contract (subscribed) будет создана. или отревочена.

в каком классе исполняется смартконтракт (слотконтракт)?¶

Это не вполне корректный вопрос. Часть - в айтем процессоре, часть - в клиент-сервере. Надо уточнить вопрос.

как юзеру получить список всех своих сохраненных контрактов? по ключам? по hashId?¶

В данный момент никак. Подписка вешается на слот-контракт а не на юзера - система не знает ничего о юзере, она оперирует только контрактами, юзеров как таковых у ноды нет. Сейчас не делаем

что храним в БД постгреса - юзерские контракты или слот-контракты? Или сущность слот-контракта собирается из набора данных из разных таблиц БД?¶

На данном этапе надо хранить последнюю ревизию слот-контракта и юзерские.

в БД у одного контракта есть множество подписок с expires_at. как считать общее время хранения?¶

Очевидно, по самой последней. Хранится одна копия контракта, а доступ к ней возможен со всех подписок с неистекшим сроком. Доступ через подписку с истекшим сроком невозможен, мы ее удаляем. Надо особенно отметить, что если слот-контракт истек, при продлении мы создаем новую подписку на тот контент, который есть в теле слот-контракта (последний уцелевший), если в базе и были более новые версии, то они не обязательно сохранились, так что новая подписка начинается с того, что есть в теле слот-контракта. В отличие от случая продления существующей подписки.

что насчет ресинка хранилища? (например добавляем новую ноду в сеть)¶

Хранилище должно находиться строго в основной базе. Тогда базовые процедуры будут ресинкать слот-контракт и его environment. Дополнительные процедуры синхронизациии добавим в следующих итерациях

может быть balance слота нужно сохранять вместе с таймстампом начала срока хранения?¶

В принципе можно сдеоать по разному. Например, можно баланс просто вычислять каждый раз из размера хранимого контента и текущего значения expiresAt. Это более простой способ. То есть алгоритм получается такой:

• рассчитать текущий баланс (фактически, остаток на данный момент)

• рассчитать новый объем хранения после выполнения операции И/ИЛИ дополнить баланс если есть оплата

• для нового обхема хранения рассчитать expiresAt. Если он окажется в прошлом, система его штатно грохнет сама.