Update resource_groups.md #35
Conversation
davidiw
requested review from
aching,
wrwg,
zekun000,
movekevin and
igor-aptos
aips/resource_groups.md
Outdated
| @@ -99,6 +99,8 @@ During compilation and publishing, these attributes are checked to ensure that: | |||
|
|
|||
| From a storage perspective, a resource group is stored as a BCS-encoded `BTreeMap<StructTag, BCS encoded MoveValue>`, where a `StructTag` is a known structure in Move of the form: `{ account: Address, module_name: String, struct_name: String }`. Whereas, a typical resource is stored as a `BCS encoded MoveValue`. | |||
|
|
|||
| Resource groups introduce a new storage access path: `ResourceGroup` to distinguish from existing access paths. This provides a cleaner interface and segration of different types of storage. This becomes advantageous to indexers and other direct readers of storage that can now parse storage without inspecting module metadata. | |||
There was a problem hiding this comment.
Might be a bit lengthy but can we also clarify that since the current APIs only allow accessing specific resources via Resource access path or modules via Module access path, there's no way to access a specific resource group and load all of the contained resources. These individual resources, however, can be accessed via the list account resources API or by referring to each of these resources specifically. There are no use cases for fetching resource groups and they can be viewed as an internal data structure for smart contracts and VM.
aips/resource_groups.md
Outdated
| 3. Each entry within a resource group has a `resource_group` attribute. | ||
| 4. The `container` parameter is set to a struct that is labeled as a `resource_group_container`. | ||
| 5. During upgrade, an existing `struct` cannot either enter or leave a `resource_group`. | ||
| 1. A `resource_group_member` has no abilities and no fields. |
There was a problem hiding this comment.
This is a typo right? The members must have fields to be useful? (as they do above).
There was a problem hiding this comment.
ugh, yes, this is resource_group
|
|
||
| ```move | ||
| #[resource_group(container = aptos_framework::object::ObjectGroup)] | ||
| #[resource_group_member(group = aptos_framework::object::ObjectGroup)] | ||
| struct Object has key { |
There was a problem hiding this comment.
If this resource_group_member attribute is present, does it mean we'll enforce that these structs can only be used as part of that resource group, and not in any other resource group / on its own?
There was a problem hiding this comment.
yes, will make sure that is clear in the writing.
aips/resource_groups.md
Outdated
| 2. The `scope` within the `resource_group_member` can only become more permissive, that is it can either remain at a remain at the same level of accessibility or increase to the next. | ||
| 3. Each entry within a resource group has a `resource_group_member` attribute. | ||
| 4. The `group` parameter is set to a struct that is labeled as a `resource_group`. | ||
| 5. During upgrade, an existing `struct` cannot either enter or leave a `resource_group_member`. |
There was a problem hiding this comment.
I read the AIP but I'm still not sure why we have these constraints? I figure it's so we don't have to deal with backfilling / null data respectively?
There was a problem hiding this comment.
you'll end up in a situation where data is lost, I'll make that clearer. Specifically, if a struct enters a resource group any existing data will become inaccessible. Now one could theoretically add key to something after the fact and potentially make that into a resource group. But key + resource group go hand in hand.
Adding some updates after wrapping up the first complete implementation:
AIP seems like it is probably ready for community review. Will discuss with gatekeepers.