quick reminder: please fill out the GSoC eval soon.
also, if you're interested in coming to our summit, please add yourself to the wiki. I'm happy to cover your travel costs as well.
reosarevok
The large travel costs between Spain and Spain
ruaok
may not be much, but is symbolic.
reosarevok
Although to be fair there's absurdly high prices inside the country at times...
Sure, sure :)
Lotheric_ joined the channel
Lotheric has quit
Lotheric_ is now known as Lotheric
Lotheric has quit
gr0uch0mars has quit
jwf joined the channel
alastairp
ruaok: pristine__: I added some comments to the schema PR
I wasn't following the original discussion on IRC, so I'm a bit unclear about exactly what you're wanting to store here. my gut feel is that there's some items missing
ruaok
the goal is to store the information about recommender scripts having used a track recently.
to avoid re-recommending tracks too soon.
alastairp
ah, that scope is a little less than I thought, then
ruaok
and each recommender needs its own time domain for that -- this table should enable that.
I'll read the other comments a bit later.
alastairp
yeah, I wonder about the time domains
I suggested a "recommender session" join table, or similar
so that a recommender can keep track of how it's run over multiple times
I don't think grouping by added date is a good way of doing this, if this is a feature that you want
ruaok
recommender sessions. great idea.
likely just a JSON field so the recommender can store arbitrary context?
and at this point when the recommender runs is unclear. that may depend on the recommender.
Lotheric joined the channel
pristine__
> so that the recommender can keep track of how it is run over multiple times
What would that info be like?
alastairp
yeah, you'd definitely have to control that json block. I was thinking that it'd be great for a recommender to say "this is all the input that I used to calculate this session", but that could just as easily be "all of listenbrainz"
pristine__: imagine that the same recommender runs every week
so you want to be able to easily get the results of the recommender for user x for week 1, week 2, week 3
pristine__
till week n?
alastairp
it doesn't matter how many weeks there are, just that you can separate them
I'd do it by adding a join table that has recommender id, user id, date, and some 'data field' that the recommender can store
like ruaok says, jsonb would be ok
ruaok
great forward thinking, alastairp.
alastairp
then the join table instead of linking to a recommender, links to the session
and now you don't need the user id or date in the recording table
> 5:33 PM <alastairp> then the join table instead of linking to a recommender, links to the session
this join table, I mean the one already in the PR, there'll be 2 now
ruaok nods
ruaok
I like it.
pristine__
So we clip of cf_recording_recommemder_join table and have recommender_session table instead?