Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Remove a max supply record on collection's destruction #11593

Merged
merged 4 commits into from
Jun 7, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions frame/uniques/src/functions.rs
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,7 @@ impl<T: Config<I>, I: 'static> Pallet<T, I> {
Attribute::<T, I>::remove_prefix((&collection,), None);
CollectionAccount::<T, I>::remove(&collection_details.owner, &collection);
T::Currency::unreserve(&collection_details.owner, collection_details.total_deposit);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make sense to have the collections ID not be user controlled, but have it be an ever increasing integer.
That way the ID of a unique collection is itself unique.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've also considered this in the context of fungible assets, because there can be issues when they are used on other chains. For example, if some asset is in the reserve account of parachain A, the owner nukes it, that asset's reserve-backed mint is in use on parachain A, and someone creates a new asset in the same ID, the users on para A wouldn't necessarily know about it.

We could also go the route of anonymous proxy like ID where we hash some module prefix with the block number / extrinsic index and get a 32 byte identifier.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I completely agree with you. In V2 I've made the ids auto-generated, so you won't be able to get the same ID twice.
At the same time, the main idea behind the current IDs model is that you can batch your call and execute different actions on your collection since you know its ID.

CollectionMaxSupply::<T, I>::remove(&collection);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for not having the max supply be part or CollectionDetails but having it in an additional map?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to avoid the unnecessary migrations, especially when we're going full speed ahead with Uniques V2


Self::deposit_event(Event::Destroyed { collection });

Expand Down
8 changes: 8 additions & 0 deletions frame/uniques/src/tests.rs
Original file line number Diff line number Diff line change
Expand Up @@ -684,5 +684,13 @@ fn max_supply_should_work() {
Uniques::mint(Origin::signed(user_id), collection_id, 2, user_id),
Error::<Test>::MaxSupplyReached
);

// validate we remove the CollectionMaxSupply record when we destroy the collection
assert_ok!(Uniques::destroy(
Origin::signed(user_id),
collection_id,
Collection::<Test>::get(collection_id).unwrap().destroy_witness()
));
assert!(!CollectionMaxSupply::<Test>::contains_key(collection_id));
});
}
Loading