#metabrainz

/

      • samj1912
        bitmap: the corresponding mbsssss PR for urls https://github.com/metabrainz/mbsssss/pull/9
      • bitmap
        basically we never require anyone to run SQL scripts for the bi-weekly releases to get their server to work, only at schema change time
      • alastairp
        right, that's a nice concrete rule
      • bitmap
        but for things like the json_dump or sitemaps schema we've made exceptions, because those are basically only used in production, they aren't needed for the website or web service
      • Leo_Verto
      • reosarevok
        Yay
      • alastairp
        OK, I need to work out then how often we might want to do schema changes and what the process for making one of those changes will be, and compare that with how many people we actually expect to be running one of these servers
      • thanks
      • bitmap
        didn't mean to imply it's only about mbs users either, it wouldn't be technically hard to do/automate incremental schema updates, but it's for customers who work with the schema directly too
      • afaiu, idk how many actually do that
      • vk has quit
      • heyoni joined the channel
      • Leftmost
        That's a nice recommendation!
      • Leftmost presses the "forte" button. :P
      • heyoni has quit
      • kyan joined the channel
      • iliekcomputers, thoughts on being able to remove individual listens? There are some in my listening history that are bogus (usually a bad client submitting duplicates).
      • iliekcomputers
        Leftmost: there is a ticket open for this (LB-1), I'm not sure how easy (or hard) it is to remove rows from BigQuery so not sure exactly how to do this yet.
      • BrainzBot
        LB-1: Add a method to remove listens https://tickets.metabrainz.org/browse/LB-1
      • alastairp
        Leftmost: in theory "we never remove anything"
      • but I'm not sure about bad listens compared to bad life choices
      • iliekcomputers
        although duplicate submissions should be detected by our system ideally
      • Leftmost
        The problem is the bad client submitted them (to last.fm) at different times.
      • alastairp
        you could also argue that a few bad listens in your entire history is just noise :)
      • Leftmost
        Mostly, but it bothers me. :P
      • Leo_Verto
        maybe a way to "ignore" listens for future suggestion engines would work?
      • Leftmost
        Oh, speaking of things that bother me, any suggestions on how to make my music collection available for listening on Android while preserving MBID tags?
      • Leo_Verto
        what format is your collection in?
      • Leftmost
        FLAC.
      • samj1912
        bitmap: do you know of any other way to deal with the target-type issue than the table name?
      • Leo_Verto
        I mean, you could just keep it as flac but ogg would use quite a bit less space
      • samj1912
        If not, I guess I could just make a dictionary to map table names to target types
      • bitmap
        I haven't checked the models but the target type might just be available in the path somewhere
      • Leftmost
        Leo_Verto, even as Vorbis I'd likely not be able to fit my entire collection on the phone itself. I need some sort of cloud+player solution. :P
      • bitmap
        though there is nothing too terrible about getting it from the table name
      • Leo_Verto
        ah
      • anthony25_ joined the channel
      • bitmap
        the link_type should have entity0_type and entity1_type at least, but that just saves you a regex replacement
      • samj1912
        entity_type0
      • yes
      • bitmap
        not that we add new entity types often, but not hardcoding the mapping would be nice. we spent ages removing that sort of stuff from MBS
      • samj1912
        hmm, maybe I can just take the entity type that is not URL and replace the underscore with hyphens?
      • anthony25 has quit
      • anthony25_ is now known as anthony25
      • bitmap
        yeah
      • assuming we never add any l_url_url relationship types ;)
      • samj1912
        the problem is I will have to hardcode this anyway https://github.com/samj1912/sir/blob/3395066c3a...
      • bitmap
        ah, right. I guess it doesn't matter then
      • maybe mbs should move https://github.com/metabrainz/musicbrainz-serve... into a separate repo so other projects can use it
      • we read that and in the code do something like entities_with(['mbid', 'relatable'])
      • samj1912
        bitmap: is it releasegroup or release-group?
      • bitmap
        I believe release-group would be correct since that's what we use for the resource name and inc params
      • unless there is another instance where we use type names I'm unaware of
      • samj1912
      • bitmap
        hm :/
      • is that for a field name or a field value?
      • samj1912
        value I guess
      • but its just sir
      • bitmap
      • works, but releasegroup doesn't
      • so I think we should change both to release-group
      • samj1912
        done
      • github joined the channel
      • github
        [sir] samj1912 opened pull request #48: Fix type name for release-group (releasegroup -> release-group) (master...fixanno) https://git.io/vdpmr
      • github has left the channel
      • samj1912
        and I also updated the URL PR
      • CardinalWolseley has quit
      • CardinalWolseley joined the channel
      • kahu has quit
      • github joined the channel
      • github
        [sir] samj1912 closed pull request #48: Fix type name for release-group (releasegroup -> release-group) (master...fixanno) https://git.io/vdpmr
      • github has left the channel
      • samj1912 is surprised there are only 6kish series
      • github joined the channel
      • [sir] samj1912 closed pull request #47: SOLR-67: Bring URL to current search parity (master...solr67) https://git.io/vdNlx
      • github has left the channel
      • samj1912
        we are done 🎉
      • now onto making it better :P
      • http://35.193.119.46:8983/solr/ for those who want to try out the current solr search, almost everything should be indexed (*almost*) except for work, url and events (which are currently being indexed)
      • github joined the channel
      • github
        [sir] samj1912 opened pull request #49: Add missing recording.video path to Work extra paths (master...fixwork) https://git.io/vdpZi
      • github has left the channel
      • samj1912
        hmm, all these extra paths are getting hard to keep a track of
      • there should be an easier way to add them without forgetting
      • github joined the channel
      • github
        [sir] samj1912 closed pull request #49: Add missing paths to Work extra paths (master...fixwork) https://git.io/vdpZi
      • github has left the channel
      • samj1912
        they slow down indexing a lot if you forget to add them
      • bitmap
        does it crash if they're missing? or just have to actually query them separately from the db
      • samj1912
        no it just queries them seperately
      • causes quite an overhead in indexing
      • and the extra paths are really repetitive too
      • since a lot of the entities share similar convert functions
      • samj1912 really wishes these functions were classes :P
      • although not really sure if it makes sense to couple them
      • bitmap
        eww
      • why? :)
      • samj1912
        extra paths and convert functions :P
      • so I could simply build up the a extra_path attribute in the class
      • also would be easier to manage the code since we would have all the related functions together
      • right now they are just everywhere in the file which makes it really hard to navigate up the call stack
      • this will probably be easier once we unify the relationship output
      • and have uniform functions
      • instead of convert_work_artist_relationship we have a simple convert_artist_relationship
      • that way instead of defining and call functions, we can simple list all the relationships and python can pick the functions appropriately
      • samj1912 loves python meta-programming
      • it reduces code and manual effort
      • also part of the reason I love python so much :P
      • bitmap
        and people say perl is scary :P
      • samj1912
        hehe :P
      • bitmap
        blessed hashes are scarier than classes in name only
      • samj1912
        that sounds like something out of an RPG XD
      • reosarevok
        A stoner RPG
      • MajorLurker joined the channel
      • Mineo joined the channel
      • CardinalWolseley has quit
      • heyoni joined the channel
      • github joined the channel
      • github
        [musicbrainz-server] yvanzo closed pull request #564: MBS-9519: Hide biography, website/homepage, and collections description of limiter users from not-logged-in users (master...mbs-9519-hide-user-text) https://git.io/vdxcR
      • github has left the channel