alastairp: #1183 is ready -- sorry that got to be a bit of a big PR. but it cleans a lot of things up and puts us on the right track for mapping work.
alastairp
hello ruaok
cool, will do
ruaok
I'll submit a PR for getting typesense into production later. no need to shove that into this PR.
alastairp
great
ruaok
this PR feels good, I have to say. feeling like a giant ball of headaches is getting tucked away.
now, do we still need MessyBrainz?
alastairp
mmm
you said a few things earlier in the week, and I think based on that we still do
ruaok
only for internal reference, I think. I'm not advocating that we get rid of it, but its utility to us has diminished.
I suspect that at some point later we'll be happy to have it.
alastairp
I'm not convinced that listen -> typesense -> MB is going to give us everything that we need
and I worry that we'll end up like lfm with a bunch of dodgy mappings
ruaok
I think it will give us better results than the MSID mapping I had.
> and I worry that we'll end up like lfm with a bunch of dodgy mappings
I hear that loud and clear.
which is why I am going to create a separate table in timescale for keeping the matches
so that it can be dropped and recreated at any time.
alastairp
so I'm all for putting stuff into messybrainz still and then doing a timesense lookup at import time to get an id
great, I'm all for that, then
ruaok
agreed. I'm not suggesting that we do anything with MSB yet, it was mostly just a thought.
alastairp
great. just checking
sumedh has quit
ruaok
Mr_Monkey: shall we get your DB running the latest schema?
I'm looking at the planning doc now.
Mr_Monkey
Sure. I'm just starting it up with port exposed, let me have a look and see if I can figure it out
ruaok
k
> item count (this is a computed field, not in the DB schema)
Mr_Monkey: computed where? in the python code? could/should it be computed in JS?
Mr_Monkey
As I'm writing a bit of python for the `user_name/playlists` route I can definitely say it would be better there to load the playlists without the tracks, and not have to do the computation in JS.
ruaok
ok
Mr_Monkey
Now, that being said, we could also decide not to show the track count in the playlistS view, but only on single playlist view in which case we can compute in JS
ruaok
let me make a plan to store the data. we're not committed to using that field.
Mr_Monkey
Now that I think about it, for the single playlist view it'll be better to compute it in JS (since the count will change with addition/deletions and we need to keep track of it anyway)
We could also have a separate endpoint to return a playlist's item count like we do for user's listen count
ruaok
we should not do that for something that can be computed reasonsably easily.
alastairp
mm, remind me why we need this field?
from reading the document I understand that it's not in xspf, but we have/want/need it?
ruaok
the latter point is correct. I'm also with you that it doesn't make sense to store computed values.
though if someone wanted to get just the metadata, without fetching the tracks, then yes.
but our API doesn't support that... yet.
Mr_Monkey
ruaok, alastairp : I think there's a typo in the playlist SQL update script. I'm getting `psql:/tmp/2020-11-21-playlists.sql:29: ERROR: column "copied_from" does not exist` and I think the end of line 29 should read `ON playlist.playlist (copied_from_id);` instead of `ON playlist.playlist (copied_from);` Can you please confirm? I'll commit the change if so.
alastairp
yes, I changed the name of the field but I must have missed the index
sorry for that Mr_Monkey
Mr_Monkey
Okidoke, will commit.
alastairp
ruaok: right, I guess I'm asking why do we need to send a number which is the length? what's stopping someone from just doing len(tracks) ?
oh, saw your comment about metadata
that's a good point
ruaok
alastairp: len(tracks) was my point. save for the metadata bit.
I'll add a field in the spec, even if we dont use it.
Mr_Monkey
alastairp: There's also some occurences of `copied_from` in some SQL commands in db/playlist.py ; Shall I fix them too?
alastairp
:( I think so
let me have a quick look at my git log
yeah, any occurrence of copied_from that wasn't changed to _to should be updated
if only I had written tests
Mr_Monkey
👍 It's only two instances, in the same file. Committing.
And pushed
alastairp
there is the update file, but there are also the files in the create_tables and create_indexes
So it's just a setup thing, where you can start with lowercase but then it won't redirect to it from uppercase or something?
Anyway, it should work fine I think
Just make a jspf page
ruaok
thx.
do you happen to know how to make an anchor?
is that just heading?
== Achors ==
+n
so it appears.
reosarevok
Yeah, IIRC it is
Although if you want to make sure the link is long-lasting, you better set this page for transclusion too, so that one of us needs to allow changes to it :)
(the link to /doc/ anyway, I guess a link to the wiki would always have that risk)
I did just add it to the web page. let me add a link to the web page in lieu of the gist.
done.
sumedh joined the channel
sumedh has quit
davic joined the channel
Mr_Monkey
ruaok, alastairp sorry to disturb you again, I've got a python issue I don't know how to fix: `ujson.dump` doesn't like the output of `serialize_jspf`: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x9a in position 83: invalid start byte`