Руководство по миграции Dynamic Fields

С выпуском Sui 0.13.0 мы заменим концепцию дочерних объектов динамическими полями. Это критическое изменение : API-интерфейсы Move для взаимодействия с дочерними объектами в sui::transfer( transfer_to_objectи transfer_to_object_id) удаляются и заменяются динамическими полями sui::dynamic_fieldи для работы с ними.sui::dynamic_object_field

Чтобы избежать ошибок в приложениях, использующих дочерние объекты, следуйте приведенному ниже руководству по миграции и будьте готовы внести изменения, когда Devnet обновится до версии 0.13.0 (см.#devnet-обновленияв Discord для анонса). Чтобы свести к минимуму время простоя вашего приложения, подождите, чтобы внести изменения, пока не выйдет обновление Devnet, так как новые API-интерфейсы для взаимодействия с динамическими полями будут недоступны до этого момента.

Что такое динамические поля?

Динамические поля являются обобщением дочерних объектов. Они позволяют разработчикам Sui Move расширять свои структуры новыми данными на лету.

Они устраняют основное неудобство, связанное с дочерними объектами , которые требуют передачи своей цепочки владения предком (его родителя, родителя его родителя и т. д. до корневого объекта, принадлежащего отправителю) через entryфункцию. Это ограничение делало работу с глубоко вложенными дочерними объектами болезненной и не поддерживало использование, когда цепочка предков не могла быть известна в начале транзакции (т. е. динамическая загрузка дочерних объектов). При использовании динамических полей в функцию передается только корневой объект entry, а доступ к его динамическим полям возможен «на лету» во время выполнения транзакции. (На самом деле, передача значения динамического поля в качестве входных данных для функции ввода теперь не будет работать).

Они также имеют несколько других улучшений:

Удержание любой storeценности, а не только объектов.
Маркировка и поиск полей по имени (где имя может быть любым copy, drop, storeзначением).
Включение новых сетевых хранилищ ключей и значений, таких как Table(однородные ключи и значения) и Bag(разнородные ключи и значения).

Сходите с ума от них! Мы слышали много разочарований по поводу отсутствия структур данных и невозможности реализовать их в Move. Вы должны быть в состоянии эффективно реализовать все виды структур данных в Move прямо сейчас! Будь то связанная хэш-карта, префиксное дерево или просто связанный список. Динамические поля требуют чтения/записи объектов в хранилище. Мы по-прежнему ожидаем, что простые векторы будут более эффективными, чем сложные структуры данных для очень небольшого количества элементов.

Текущие ограничения

Мы все еще активно работаем над некоторыми частями Dynamic Fields, но нам не терпелось поделиться с вами этой функцией, чтобы посмотреть, что вы можете с ее помощью создать, и получить ваши отзывы. При использовании этой функции следите за следующими известными проблемами, которые будут устранены в следующем выпуске:

removeдля динамических полей в настоящее время неоптимизирован и не дает полного возмещения объема хранилища. Под капотом dynamic_field(и dynamic_object_field) создает Fieldобъекты для хранения своих пар ключ-значение.
В настоящее время для s нет exists_функции для dynamic_fieldпроверки того, определено ли уже поле с заданным именем в объекте.
Существуют некоторые потенциальные проблемы с устойчивостью/непротиворечивостью объектов динамических полей: если валидатор выходит из строя и снова включается при обработке транзакции с динамическими полями, он может быть не в состоянии продолжить обработку транзакций с этими объектами. Мы активно работаем над решением этой проблемы.

Руководство по миграции

Приведенные ниже предложения помогут преобразовать любое существующее использование дочерних объектов в использование динамических полей, но учтите, что во многих случаях вам может потребоваться переосмыслить использование API. Во многих случаях код можно сделать проще или удобнее для конечного пользователя. Приведенные ниже примеры предназначены для того, чтобы помочь с заменой, чтобы все работало.

Замените вызовы `transfer_to_object`на`add`

// Old, Child Object API 
use sui::transfer; 
transfer::transfer_to_object(&mut parent, child) 

// New, Dynamic Field API 
use sui::dynamic_object_field as ofield; 
let id = object::id(&child); 
ofield::add(&mut parent.id, id, child);

Новый API добавляет поле parentс childидентификатором 's ID в качестве имени и childв качестве значения.

Замените цепочки предков владения в `entry`забавах вызовами `borrow`, `borrow_mut`или`remove`

(Примечание: это предложение предполагает, что вы следовали предыдущему предложению по переходу с transfer_to_objectиспользования ofield::addидентификатора child's ID в качестве имени поля).

// Child, Parent, GrandParent are all Objects
struct Child       has key, store { id: UID, /* ... */ }
struct Parent      has key, store { id: UID, /* ... */ }
struct GrandParent has key, store { id: UID, /* ... */ }

// Old, Child Object API
entry fun read_child(gp: &GrandParent, p: &Parent, c: &Child) {
    /* ... */
}
entry fun write_child(gp: &mut GrandParent, p: &mut Parent, c: &mut Child) {
    /* ... */
}

entry fun take_child(gp: &mut GrandParent, p: &mut Parent, c: Child) {
    /* ... */
}

// New, Dynamic Field API
use sui::dynamic_object_field as ofield;

entry fun read_child(gp: &GrandParent, pid: ID, cid: ID) {
    let p = ofield::borrow<ID, Parent>(&gp.id, pid);
    let c = ofield::borrow<ID, Child>(&p.id, cid);
    /* ... */
}

entry fun write_child(gp: &mut GrandParent, pid: ID, cid: ID) {
    let p = ofield::borrow_mut<ID, Parent>(&mut gp.id, pid);
    let c = ofield::borrow_mut<ID, Child>(&mut p.id, cid);
    /* ... */
}

entry fun take_child(gp: &mut GrandParent, pid: ID, cid: ID) {
    let p = ofield::borrow_mut<ID, Parent>(&mut gp.id, pid);
    let c = ofield::remove<ID, Child>(&mut p.id, cid);
    /* ... */
}

Узнайте больше о Dynamic Fields

Узнать больше о Sui

Стройте вместе с нами!!

Мы в восторге от того, как разворачивается будущее, и приглашаем создателей и строителей Присоединяйтесь к нам.

Tags: resources Sui