#metabrainz

/

      • v6lur has quit
      • supersandro2000 has quit
      • supersandro2000 joined the channel
      • d4rkie has quit
      • Nyanko-sensei joined the channel
      • dseomn has quit
      • dseomn joined the channel
      • dseomn has quit
      • dseomn_ has quit
      • dseomn joined the channel
      • dseomn has left the channel
      • dseomn joined the channel
      • Lotheric__ is now known as Lotheric
      • davic has quit
      • sumedh joined the channel
      • MajorLur_ joined the channel
      • MajorLur_ is now known as MajorLurker_
      • MajorLurker_ has quit
      • thomasross has quit
      • sumedh has quit
      • MajorLur_ joined the channel
      • MajorLur_ is now known as MajorLurker_
      • MajorLurker_ has quit
      • yvanzo has quit
      • yvanzo joined the channel
      • sumedh joined the channel
      • v6lur joined the channel
      • ruaok has quit
      • ruaok joined the channel
      • sumedh has quit
      • sumedh joined the channel
      • Gazooo79494 has quit
      • ruaok
        mooooin!
      • Gazooo79494 joined the channel
      • 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
      • Mr_Monkey
        Those have the correct column name
      • ruaok
      • updated the gist.
      • alastairp: now that there are two namespaces, I used anchors to differentiate them.
      • alastairp
        ruaok: sure thing. I'll run this past my semantic web guy
      • ruaok
        reosarevok: is it bad form to have a wiki page that starts with a lower case?
      • alastairp
        I think it might be better to do it as a path, because then in the definition document you can make the fields available at the anchor
      • reosarevok
        Dunno? :D
      • Wait, you mean the title or the content?
      • alastairp
      • ruaok
      • :)
      • reosarevok
        IIRC some older versions of mediawiki didn't allow that but now they do?
      • ruaok
        I need to put docs on this page: `https://musicbrainz.org/doc/jspf#playlist`
      • reosarevok
      • 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)
      • ruaok
        that's the plan.
      • reosarevok
        Ok
      • diru1100 joined the channel
      • ruaok
      • all proper semantic web and shit. :)
      • Mr_Monkey
        Noice
      • ruaok
        does all that make sense, Mr_Monkey ? cover all your needs?
      • Mr_Monkey
        Yes, I think that'll do nicely !
      • ruaok
        great.
      • Mr_Monkey
        In the meantime I've made some progress with the flask view endpoints.
      • Still need to implement that new structure with extensions in the React code and we should be set !
      • I've already been able to create a playlist from the front-end page, so we're in business
      • We're missing a couple of endpoints for playlists (edit, copy), but it looks like it'll be easy to add.
      • ruaok
        yes, those should be quick to do .
      • speaking of which, lets pick a day next week to hack on the playlist stuff, shall we?
      • wed?
      • 🤣
      • alastairp
        wednesday seems fine to me
      • Mr_Monkey
        Can do wednesday
      • ruaok
        into the calendar it goes.
      • Mr_Monkey
        Ditto.
      • Ah, there's on more field needed in the playlist JSPF extension ruaok : `last_modified_at`
      • ruaok
      • Mr_Monkey
        Ah, sorry, I was looking at the gist …
      • ruaok
        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`