search

SaraBee / MCGJ

A Flask web app for running collaborative playlist parties
27 stars 7 forks source link

Allow browsing list of already submitted songs #23

Open lamarqua opened 3 years ago

lamarqua commented 3 years ago

It'd be nice to have an easily accessible list of songs that we submitted in previous MCGs for us that try to not repeat ourselves :P

nebkor commented 3 years ago

Question for @SaraBee: would it be reasonable to store tracks in the DB with a "played" value of 0? Then you could easily have a query like select track, title, track_url from tracks where played = 0 and person = ?login for building a list on your profile.

EDIT: I just realized that Adrien was asking for things that had been played, which is a similar query, even if it's a different UI/UX :)

SaraBee commented 3 years ago

@nebkor I think it's totally reasonable to keep unplayed tracks around, but what I would do if I were me would be to also unset the session_id for non-session tracks and use that in conjunction with played = 0 to figure out what's a staging playlist track.

The session_id is set automatically when creating the track from within the session context; you could have it not get set when creating a track within a staging playlist context and/or unset it when moving a track to a staging playlist.

nebkor commented 3 years ago

Man, if you were you, you'd be a frickin' GENIUS! :)

I love using an unset session_id as part of a staging list, which I imagine you would build directly on your profile.

However, what about tracks you've queued during a session that didn't get played? Would they have an unset session as well, but retain a cue_date? To be honest, this was the primary mechanism I was envisioning for how one might build a staging list as a user.

SaraBee commented 3 years ago

This is non-obvious, but cue_date is when the track got added to a round (rather than the "unplayed tracks" section at the top) and is used to determine ordering within a round. So if it is going in a staging list, it shouldn't have a cue_date. Does that help at all?

nebkor commented 3 years ago

That makes perfect sense.

Would it be reasonable to add a column for like ... "submitted_date" or something like that? Stepping back, this is motivated by trying to keep all the data in the tracks table, when it might make sense to have a separate table to keep track of things like "tracks submitted by a person".