Solution 1. Vector table
Overview:
Pros:
similar architecture to
addaddress
remallnfts
works as spec'dVector can be emptied in single call without iterating through all the objects. This allows for remallnfts to work flawlessly
Cons:
Limit on number of NFTs that can be mapped
Requires limit on number of NFTs that can be mapped to any single FIO Address due to vector search linear compute time on checking existing entries and checking for items to remove. Like addpubaddress vector but more limited since it iterates with a larger object
Requires update to support
get_nfts_hash
Can’t do it unless all the data is duplicated in another table mapped by sha256 (fioaddress+chaincode+contractaddress+tokenid => hash)
If mapped, we would need an admin cleanup task these cannot be deleted with all vector entries w/ remallnfts, back to square one.
Solution 2. Multi-index container
Overview:
Pros:
Unlimited NFTs due to use of multi index container
Good search time adding/removing small entries
Supports
get_nfts_hash
Cons:
Cannot remove all nfts.
Can do 5 at a time, newest to oldest or vice versa
By making
remallnfts
have less custom error responses and removing some other checks I may be able to salvage enough cpu time to clean out more NFTs in a single call
Cannot remove NFTs for a FIOAddress in
xferaddress
orburnexpired
.For
xferaddress
, users would need to empty their NFTs using multiple calls to remallnfts first before they can transfer.For
burnexpired
, we would need to iterate through the burning of NFTS for every FIO Address that is getting burnedBurnexpired
could skip fioaddresses that have NFTs mapped and come back to those at the end if we wanted to optimize burn.
Discussion
Recommend solution 1 and
get_nfts_hash
endpoint removed andget_nfts_contract
used alternatively
Add Comment