Replies: 3 comments
-
I think we have to integrate models together just like you mentioned. As we go further well-related models will bring muzikie more informative composite data in order to make our queries more accurate and flexible. |
Beta Was this translation helpful? Give feedback.
-
In this case:
|
Beta Was this translation helpful? Give feedback.
-
According to above, if we have
Then users can define an address as a co-artist. We can retrieve the corresponding profile info and show the name and nickName. but alternatively we can show the address if a profile was not created. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Before we created the profile module, we added the artist name as a string in the collection and audio module models. Later on we introduced the profile module, which can hold the personal information about the artist. If an account represents a band, the profile can belong to a band.
My question is, do we still need to store a property in the collection and audio modules to represent the artist? We should taker into account that collections and audios have a
creatorAddress
. Meaning, if you retrieve the information of an audio NFT, you can use thecreatorAddress
to retrieve the profile of the band or artist that created the audio.Given the above, I think we no longer need to store the artist name. Although we still need to store co-artists, or featuring artists.In which case we have to make it possible to insert:
We should also make it possible for the creator of the audio to update the co-artists from string to a Lisk 32 address.
Beta Was this translation helpful? Give feedback.
All reactions