Right now I’m able to mint NFT
My target is to check all the NFT ever created before minting a new one.
In order to do that there’s a cadence script that returns all the NFTs of the main address collection.
The problem is that, when a NFT is moved to another address, how will I be able to check all the NFTs I ever minted without rely on a classic database?
My first idea was to mint a hidden-clone of each NFT on the flow-blockchain
Am I missing some examples, what could be the best way to do so?
My initial idea was to create a collection in the main address with a list of all the token ID and their current address.
Then in the sell() function I would make sure that this collection on the main address remains updated.
Do you think that could be a good approach or is there some better way to do it?
Hey! Here I am, sorry for the delay luca! I look to discord and it lloks like that keeping a centralized database is the common choice with the help of the events. Just copy-paste from a reply of @theBusBoy#9837 on Discord:
Answering the “why” question of it writing to the db: In Flow’s resource paradigm, assets are stored within an individual’s storage. Let’s say I deploy a contract to make widgets, mint 100 of them, and then distribute them to users. I can’t just query the account that minted the 100 widgets to find the current whereabouts of them (without writing what I currently believe to be an anti-pattern that stores tokenID → userAddress on-chain in metadata).
So, we need to keep track of where these 100 widgets are and can’t make one query to track then currently, right? This is where cadence events come in. Every time a widget is transfered from account A to account B, an event is emitted that might say something like “token 12345 transferred to address B”. We get to define what data is passed in the event we’ve created, so we could also track from address etc.
These events are named, so that when we look at blocks we’re able to filter based on events that we want to know. The worker within api/src/workers exists to look for events of the desired type on every block and then to update the central database (postgres in the KittyItems example) with the information fired off from the saleoffer event.
