#metabrainz

/

      • alastairp
        _lucifer: which PR is this?
      • 2021-04-09 09950, 2021

      • alastairp
        the remote python one?
      • 2021-04-09 09953, 2021

      • _lucifer
        python3 one
      • 2021-04-09 09907, 2021

      • alastairp
        *remove python
      • 2021-04-09 09915, 2021

      • _lucifer
        yes remove python2
      • 2021-04-09 09959, 2021

      • alastairp
        what's the issue? it seems like the value is coming out as bytes, but the test is expecting it to be a string?
      • 2021-04-09 09925, 2021

      • _lucifer
        "b'2021-02-12T13:02:18'"
      • 2021-04-09 09948, 2021

      • alastairp
        oh, it's a string with the b, not a bytestring?
      • 2021-04-09 09905, 2021

      • _lucifer
        yes, i think so
      • 2021-04-09 09940, 2021

      • alastairp
        that's... odd
      • 2021-04-09 09924, 2021

      • alastairp
        right. str(b'foo_bar') -> "b'foo_bar'"
      • 2021-04-09 09946, 2021

      • _lucifer
        yeah, we need to pass an encoding there to have it behave correctly
      • 2021-04-09 09958, 2021

      • alastairp
        that's a bug. shouldn't it be b'foo_bar'.decode('utf-8') ?
      • 2021-04-09 09918, 2021

      • alastairp
        ah, you can also pass that as an arg to `str`?
      • 2021-04-09 09923, 2021

      • alastairp
        good fix, let's do it
      • 2021-04-09 09931, 2021

      • _lucifer
        str(b'foo_bar', encoding='utf-8') works
      • 2021-04-09 09933, 2021

      • alastairp
        huh. did six.ensure_text do this automatically?
      • 2021-04-09 09935, 2021

      • _lucifer
        yup
      • 2021-04-09 09946, 2021

      • _lucifer
        maybe?
      • 2021-04-09 09948, 2021

      • alastairp
        good thing for tests! thanks
      • 2021-04-09 09919, 2021

      • alastairp
        six.ensure_text(b'foo') -> 'foo'
      • 2021-04-09 09920, 2021

      • alastairp
        yep
      • 2021-04-09 09951, 2021

      • _lucifer
        i'll change that to .decode for consistency
      • 2021-04-09 09947, 2021

      • _lucifer
        so should we also encode manually before storing?
      • 2021-04-09 09910, 2021

      • _lucifer
        just for this one date key
      • 2021-04-09 09937, 2021

      • alastairp
        I'm not sure why I didn't do it explicitly on insert
      • 2021-04-09 09950, 2021

      • alastairp
        maybe because it automatically does it?
      • 2021-04-09 09901, 2021

      • _lucifer
        yes, redis automatically converts to bytes
      • 2021-04-09 09901, 2021

      • alastairp
        if it's automatic I don't mind
      • 2021-04-09 09907, 2021

      • alastairp
        ok, that's fine then.
      • 2021-04-09 09913, 2021

      • alastairp
        let's just fix it on coming out
      • 2021-04-09 09921, 2021

      • _lucifer
        cool 👍
      • 2021-04-09 09927, 2021

      • alastairp
        you had a pending question here about adding the encoding flag to the h* methods, right?
      • 2021-04-09 09943, 2021

      • _lucifer
        yes, that's in a different PR but.
      • 2021-04-09 09954, 2021

      • alastairp
        yeah, I just remembered it
      • 2021-04-09 09900, 2021

      • alastairp
        no problem, let's discuss it in that one
      • 2021-04-09 09902, 2021

      • _lucifer
        i think its right not to add those.
      • 2021-04-09 09944, 2021

      • _lucifer
        i am fine with discussing now, i'll update that PR accordingly.
      • 2021-04-09 09908, 2021

      • alastairp
        let me have a look at that pr now
      • 2021-04-09 09916, 2021

      • alastairp
        right, so if we use hincrby we can't encode the value because redis won't know which one to use
      • 2021-04-09 09940, 2021

      • _lucifer
        yeah redis will bail out with exception
      • 2021-04-09 09950, 2021

      • alastairp
        we could add it to hset, but hgetall wouldn't know which ones should be decoded and which ones not?
      • 2021-04-09 09959, 2021

      • _lucifer
        yes exactly
      • 2021-04-09 09952, 2021

      • alastairp
        what if we added hget, and added the encode field to hset, hgetall, and hget with default false?
      • 2021-04-09 09957, 2021

      • alastairp
        *encode flag
      • 2021-04-09 09906, 2021

      • alastairp
        so we can do increment, and getall
      • 2021-04-09 09921, 2021

      • alastairp
        but if someone wants to store a map of encoded data they can still do it explicitly
      • 2021-04-09 09936, 2021

      • alastairp
        I feel a bit funny about having encode true in some and false in others
      • 2021-04-09 09953, 2021

      • _lucifer
        yeah, we don't even have a usecase yet.
      • 2021-04-09 09952, 2021

      • _lucifer
        and hgetall can't handle encode=True in any case i think. it'll try to convert ints and fail i think.
      • 2021-04-09 09908, 2021

      • alastairp
        thing is, if we want to add it in an api-comatible way in the future we'll have to default it to false anyway
      • 2021-04-09 09925, 2021

      • alastairp
        right, but if someone manually does hset(hash, key, val, encode=True) for a bunch of values
      • 2021-04-09 09936, 2021

      • alastairp
        then hgetall(hash, decode=True) would work
      • 2021-04-09 09946, 2021

      • alastairp
        (assuming that they're not storing any counters)
      • 2021-04-09 09955, 2021

      • _lucifer
        yes right that.
      • 2021-04-09 09911, 2021

      • _lucifer
        do we have a usecase where we don't use counters?
      • 2021-04-09 09941, 2021

      • alastairp
        not yet
      • 2021-04-09 09926, 2021

      • alastairp
        I think that for consistency we should add the encode/decode field, but defualt it to False
      • 2021-04-09 09933, 2021

      • alastairp
        so it's there in case we need it
      • 2021-04-09 09940, 2021

      • _lucifer
        i agree with that but we'll have to live with inconsistent defaults then.
      • 2021-04-09 09928, 2021

      • alastairp
        that's not the end of the world for me
      • 2021-04-09 09951, 2021

      • _lucifer
        yeah, true.
      • 2021-04-09 09940, 2021

      • _lucifer
        ok then let's add those with default to False.
      • 2021-04-09 09946, 2021

      • alastairp
        thanks!
      • 2021-04-09 09959, 2021

      • alastairp
        I have to go to the supermarket before it starts to rain
      • 2021-04-09 09921, 2021

      • alastairp
        I think we have a bunch of things that should be able to be finished/released/deployed on monday?
      • 2021-04-09 09923, 2021

      • _lucifer
        sure, thanks!
      • 2021-04-09 09943, 2021

      • _lucifer
        yup i hope so
      • 2021-04-09 09921, 2021

      • yvanzo
        yyoung: I reviewed your application on the community forum.
      • 2021-04-09 09938, 2021

      • yyoung
        Thanks! I'll check it later, it's time for bed now :)
      • 2021-04-09 09917, 2021

      • yvanzo
        Good night then!
      • 2021-04-09 09958, 2021

      • sumedh has quit
      • 2021-04-09 09920, 2021

      • MRiddickW_ has quit
      • 2021-04-09 09929, 2021

      • chaban
        Am I missing something or is it not possible to search for standalone recordings? https://musicbrainz.org/doc/Indexed_Search_Syntax…
      • 2021-04-09 09923, 2021

      • yvanzo
      • 2021-04-09 09939, 2021

      • chaban
        Duh, I'm a dummy. Maybe it should be made a bit more obvious in the docs
      • 2021-04-09 09908, 2021

      • yvanzo
        Yes, it should really be made more obvious.
      • 2021-04-09 09908, 2021

      • chaban
        Uhm, this is weird: https://musicbrainz.org/search?query=-release%3A*… I'm getting different amount of results almost every time.
      • 2021-04-09 09934, 2021

      • chaban
        Often it's either 4, 8 or 9
      • 2021-04-09 09933, 2021

      • yvanzo
        This is weird indeed and I cannot find any explanation for this, not even indexation delay. For example, this recording is not always returned even though it does not have recent edits: https://musicbrainz.org/recording/ca2ffe94-27e2-4…
      • 2021-04-09 09937, 2021

      • yvanzo
        Cyna[m]: I reviewed your application on the community forum. (Sorry for the many editing as I accidentally posted it too early.)
      • 2021-04-09 09909, 2021

      • Cyna[m]
        Sure thanks. Yvanzo. I'll look into the comments
      • 2021-04-09 09955, 2021

      • chaban
        That's funny. I just noticed there are no stats for standalone recordings, just videos or all recordings.
      • 2021-04-09 09957, 2021

      • chaban
      • 2021-04-09 09958, 2021

      • BrainzBot
        SEARCH-651: Searching for standalone recordings provides irregular results
      • 2021-04-09 09917, 2021

      • BrainzGit
        [listenbrainz-server] mayhem merged pull request #1382 (master…mbid-mapping-deploy): Changes needed to deploy the mbid-mapping for the new LB startup service https://github.com/metabrainz/listenbrainz-server…
      • 2021-04-09 09905, 2021

      • jasondk
        Thank you ruaok, & iliekcomputers :) I will incorporate your feedback and update my proposal with it soon.
      • 2021-04-09 09948, 2021

      • ruaok
        I didn't finish reading yet -- I'll send you comments on monday.
      • 2021-04-09 09915, 2021

      • jasondk
        About the switch regarding Oauth, maybe it will help if I switch the order of the two projects in the timeline so that by the time I begin the CB project the work on oauth has been completed.
      • 2021-04-09 09901, 2021

      • jasondk
        Sounds good ruaok .
      • 2021-04-09 09928, 2021

      • ruaok
        possibly, the timing might be hard to coordinate well.
      • 2021-04-09 09924, 2021

      • ruaok
        but, I wouldn't worry so much about that -- you could add a caveat to your proposal that this goalpost might change on you midflight and that we'd adjust and not hold it against you if it threw your schedule off.
      • 2021-04-09 09953, 2021

      • ruaok
        or we might just jump in and help out with that is needed. we'll need to do this for AB and LB as well.
      • 2021-04-09 09950, 2021

      • jasondk
        Got it, either way I will keep myself updated on that project and hopefully design it in a way where its easy to switch (if its still in progress by then)
      • 2021-04-09 09914, 2021

      • ruaok
        good plan
      • 2021-04-09 09928, 2021

      • rcombs has quit
      • 2021-04-09 09915, 2021

      • Zialus_PT has quit
      • 2021-04-09 09947, 2021

      • rcombs joined the channel
      • 2021-04-09 09951, 2021

      • MRiddickW joined the channel