Add relationships tests to ensure all nft spells project values are in nft.marketplaces_info

[hildobby]

…info

Thank you for contributing to Spellbook!

Please refer to the top of the readme in the root of Spellbook to learn how to contribute to Spellbook on DuneSQL.

[jeff-dude]

if i'm following, the intention is for any new nft marketplace added to nft.trades lineage needs to also add that project to this file?

what's the ultimate end goal here between these spells and the test?

@0xRobin what do you think about this test?

[hildobby]

@jeff-dude @0xRobin I thought PRs would be the easiest to get the conversation going with issues still completely inactive

The goal with those would be to hold high level info for its sector. Those can be joined on other spells using the project column to get extra info. For now I just added some columns but more can always be added. They provide extra context that isn't necessarily available when looking at the other spells on their own. I definitely don't know the 50+ projects in there so it's nice to easily check.

Other columns could be added such as:

• has_token (& token_contract)
• documentation_link

If you disagree with the need for projects to be added here when added to other spells we can remove the test ofc but imo the person adding the project should be the most knowledgeable on those high level easy question and it only takes a minute. What do you guys think?

[0xRobin]

thanks for the write up in #4631!

I'm a fan of this as it ensure we don't have metadata-tables that become out of sync (and thus not useful) when the reference tables change.
The test is also really fast so there's no real CI overhead added. 👍

[jeff-dude]

i would suggest for now, we leave out the test, but maintain <sector>.info spells to prepare. when we finalize the nft.trades redesign, we can add this test

i've added it in the appendix section of issue #4637

[hildobby]

Closing, will reopen once the nft sector redesign is done