You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2020. It is now read-only.
At the moment we're using the new metadata filtering to select an artist's sets, which works great, apart from the fact that you have to know which artists have active sets in advance. This means that we have to hardcode some data on the front end, i.e. artist: { active: true }
But as metadata is now indexed, we could instead give all of the active sets a common property (active: true), and request all of them in one go without the speed penalty. This means we don't need to amend any front-end code when adding new artists, we only need to make one request for sets, and we can do a true random sampling for those who haven't chosen a set. Also, @ggdhines's aggregation code can deactivate sets independently once its members are classified.
At the moment we're using the new metadata filtering to select an artist's sets, which works great, apart from the fact that you have to know which artists have active sets in advance. This means that we have to hardcode some data on the front end, i.e.
artist: { active: true }
But as metadata is now indexed, we could instead give all of the active sets a common property (
active: true
), and request all of them in one go without the speed penalty. This means we don't need to amend any front-end code when adding new artists, we only need to make one request for sets, and we can do a true random sampling for those who haven't chosen a set. Also, @ggdhines's aggregation code can deactivate sets independently once its members are classified.Props to @camallen for the idea
Related to #109
The text was updated successfully, but these errors were encountered: