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.
2020-11-27 33220, 2020
alastairp
hello ruaok
2020-11-27 33227, 2020
alastairp
cool, will do
2020-11-27 33252, 2020
ruaok
I'll submit a PR for getting typesense into production later. no need to shove that into this PR.
2020-11-27 33200, 2020
alastairp
great
2020-11-27 33225, 2020
ruaok
this PR feels good, I have to say. feeling like a giant ball of headaches is getting tucked away.
2020-11-27 33234, 2020
ruaok
now, do we still need MessyBrainz?
2020-11-27 33240, 2020
alastairp
mmm
2020-11-27 33256, 2020
alastairp
you said a few things earlier in the week, and I think based on that we still do
2020-11-27 33256, 2020
ruaok
only for internal reference, I think. I'm not advocating that we get rid of it, but its utility to us has diminished.
2020-11-27 33219, 2020
ruaok
I suspect that at some point later we'll be happy to have it.
2020-11-27 33219, 2020
alastairp
I'm not convinced that listen -> typesense -> MB is going to give us everything that we need
2020-11-27 33239, 2020
alastairp
and I worry that we'll end up like lfm with a bunch of dodgy mappings
2020-11-27 33257, 2020
ruaok
I think it will give us better results than the MSID mapping I had.
2020-11-27 33207, 2020
ruaok
> and I worry that we'll end up like lfm with a bunch of dodgy mappings
2020-11-27 33211, 2020
ruaok
I hear that loud and clear.
2020-11-27 33226, 2020
ruaok
which is why I am going to create a separate table in timescale for keeping the matches
2020-11-27 33238, 2020
ruaok
so that it can be dropped and recreated at any time.
2020-11-27 33242, 2020
alastairp
so I'm all for putting stuff into messybrainz still and then doing a timesense lookup at import time to get an id
2020-11-27 33247, 2020
alastairp
great, I'm all for that, then
2020-11-27 33205, 2020
ruaok
agreed. I'm not suggesting that we do anything with MSB yet, it was mostly just a thought.
2020-11-27 33213, 2020
alastairp
great. just checking
2020-11-27 33246, 2020
sumedh has quit
2020-11-27 33205, 2020
ruaok
Mr_Monkey: shall we get your DB running the latest schema?
2020-11-27 33212, 2020
ruaok
I'm looking at the planning doc now.
2020-11-27 33229, 2020
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
2020-11-27 33241, 2020
ruaok
k
2020-11-27 33226, 2020
ruaok
> item count (this is a computed field, not in the DB schema)
2020-11-27 33255, 2020
ruaok
Mr_Monkey: computed where? in the python code? could/should it be computed in JS?
2020-11-27 33256, 2020
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.
2020-11-27 33207, 2020
ruaok
ok
2020-11-27 33231, 2020
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
2020-11-27 33215, 2020
ruaok
let me make a plan to store the data. we're not committed to using that field.
2020-11-27 33224, 2020
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)
2020-11-27 33217, 2020
Mr_Monkey
We could also have a separate endpoint to return a playlist's item count like we do for user's listen count
2020-11-27 33257, 2020
ruaok
we should not do that for something that can be computed reasonsably easily.
2020-11-27 33226, 2020
alastairp
mm, remind me why we need this field?
2020-11-27 33248, 2020
alastairp
from reading the document I understand that it's not in xspf, but we have/want/need it?
2020-11-27 33237, 2020
ruaok
the latter point is correct. I'm also with you that it doesn't make sense to store computed values.
2020-11-27 33255, 2020
ruaok
though if someone wanted to get just the metadata, without fetching the tracks, then yes.
2020-11-27 33207, 2020
ruaok
but our API doesn't support that... yet.
2020-11-27 33206, 2020
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.
2020-11-27 33258, 2020
alastairp
yes, I changed the name of the field but I must have missed the index
2020-11-27 33202, 2020
alastairp
sorry for that Mr_Monkey
2020-11-27 33213, 2020
Mr_Monkey
Okidoke, will commit.
2020-11-27 33240, 2020
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) ?
2020-11-27 33251, 2020
alastairp
oh, saw your comment about metadata
2020-11-27 33256, 2020
alastairp
that's a good point
2020-11-27 33212, 2020
ruaok
alastairp: len(tracks) was my point. save for the metadata bit.
2020-11-27 33222, 2020
ruaok
I'll add a field in the spec, even if we dont use it.
2020-11-27 33254, 2020
Mr_Monkey
alastairp: There's also some occurences of `copied_from` in some SQL commands in db/playlist.py ; Shall I fix them too?
2020-11-27 33210, 2020
alastairp
:( I think so
2020-11-27 33219, 2020
alastairp
let me have a quick look at my git log
2020-11-27 33217, 2020
alastairp
yeah, any occurrence of copied_from that wasn't changed to _to should be updated
2020-11-27 33228, 2020
alastairp
if only I had written tests
2020-11-27 33202, 2020
Mr_Monkey
đź‘Ť It's only two instances, in the same file. Committing.
2020-11-27 33252, 2020
Mr_Monkey
And pushed
2020-11-27 33259, 2020
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?
2020-11-27 33250, 2020
reosarevok
Anyway, it should work fine I think
2020-11-27 33200, 2020
reosarevok
Just make a jspf page
2020-11-27 33201, 2020
ruaok
thx.
2020-11-27 33213, 2020
ruaok
do you happen to know how to make an anchor?
2020-11-27 33219, 2020
ruaok
is that just heading?
2020-11-27 33211, 2020
ruaok
== Achors ==
2020-11-27 33213, 2020
ruaok
+n
2020-11-27 33215, 2020
ruaok
so it appears.
2020-11-27 33229, 2020
reosarevok
Yeah, IIRC it is
2020-11-27 33204, 2020
reosarevok
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 :)
2020-11-27 33217, 2020
reosarevok
(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.
2020-11-27 33255, 2020
ruaok
done.
2020-11-27 33235, 2020
sumedh joined the channel
2020-11-27 33238, 2020
sumedh has quit
2020-11-27 33222, 2020
davic joined the channel
2020-11-27 33255, 2020
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`
