#metabrainz

/

      • alastairp
        _lucifer: which PR is this?
      • the remote python one?
      • _lucifer
        python3 one
      • alastairp
        *remove python
      • _lucifer
        yes remove python2
      • 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?
      • _lucifer
        "b'2021-02-12T13:02:18'"
      • alastairp
        oh, it's a string with the b, not a bytestring?
      • _lucifer
        yes, i think so
      • alastairp
        that's... odd
      • right. str(b'foo_bar') -> "b'foo_bar'"
      • _lucifer
        yeah, we need to pass an encoding there to have it behave correctly
      • alastairp
        that's a bug. shouldn't it be b'foo_bar'.decode('utf-8') ?
      • ah, you can also pass that as an arg to `str`?
      • good fix, let's do it
      • _lucifer
        str(b'foo_bar', encoding='utf-8') works
      • alastairp
        huh. did six.ensure_text do this automatically?
      • _lucifer
        yup
      • maybe?
      • alastairp
        good thing for tests! thanks
      • six.ensure_text(b'foo') -> 'foo'
      • yep
      • _lucifer
        i'll change that to .decode for consistency
      • so should we also encode manually before storing?
      • just for this one date key
      • alastairp
        I'm not sure why I didn't do it explicitly on insert
      • maybe because it automatically does it?
      • _lucifer
        yes, redis automatically converts to bytes
      • alastairp
        if it's automatic I don't mind
      • ok, that's fine then.
      • let's just fix it on coming out
      • _lucifer
        cool đź‘Ť
      • alastairp
        you had a pending question here about adding the encoding flag to the h* methods, right?
      • _lucifer
        yes, that's in a different PR but.
      • alastairp
        yeah, I just remembered it
      • no problem, let's discuss it in that one
      • _lucifer
        i think its right not to add those.
      • i am fine with discussing now, i'll update that PR accordingly.
      • alastairp
        let me have a look at that pr now
      • right, so if we use hincrby we can't encode the value because redis won't know which one to use
      • _lucifer
        yeah redis will bail out with exception
      • alastairp
        we could add it to hset, but hgetall wouldn't know which ones should be decoded and which ones not?
      • _lucifer
        yes exactly
      • alastairp
        what if we added hget, and added the encode field to hset, hgetall, and hget with default false?
      • *encode flag
      • so we can do increment, and getall
      • but if someone wants to store a map of encoded data they can still do it explicitly
      • I feel a bit funny about having encode true in some and false in others
      • _lucifer
        yeah, we don't even have a usecase yet.
      • and hgetall can't handle encode=True in any case i think. it'll try to convert ints and fail i think.
      • 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
      • right, but if someone manually does hset(hash, key, val, encode=True) for a bunch of values
      • then hgetall(hash, decode=True) would work
      • (assuming that they're not storing any counters)
      • _lucifer
        yes right that.
      • do we have a usecase where we don't use counters?
      • alastairp
        not yet
      • I think that for consistency we should add the encode/decode field, but defualt it to False
      • so it's there in case we need it
      • _lucifer
        i agree with that but we'll have to live with inconsistent defaults then.
      • alastairp
        that's not the end of the world for me
      • _lucifer
        yeah, true.
      • ok then let's add those with default to False.
      • alastairp
        thanks!
      • I have to go to the supermarket before it starts to rain
      • I think we have a bunch of things that should be able to be finished/released/deployed on monday?
      • _lucifer
        sure, thanks!
      • yup i hope so
      • yvanzo
        yyoung: I reviewed your application on the community forum.
      • yyoung
        Thanks! I'll check it later, it's time for bed now :)
      • yvanzo
        Good night then!
      • sumedh has quit
      • MRiddickW_ has quit
      • chaban
        Am I missing something or is it not possible to search for standalone recordings? https://musicbrainz.org/doc/Indexed_Search_Synt...
      • yvanzo
      • chaban
        Duh, I'm a dummy. Maybe it should be made a bit more obvious in the docs
      • yvanzo
        Yes, it should really be made more obvious.
      • chaban
        Uhm, this is weird: https://musicbrainz.org/search?query=-release%3... I'm getting different amount of results almost every time.
      • Often it's either 4, 8 or 9
      • 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...
      • Cyna[m]: I reviewed your application on the community forum. (Sorry for the many editing as I accidentally posted it too early.)
      • Cyna[m]
        Sure thanks. Yvanzo. I'll look into the comments
      • chaban
        That's funny. I just noticed there are no stats for standalone recordings, just videos or all recordings.
      • BrainzBot
        SEARCH-651: Searching for standalone recordings provides irregular results
      • 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-serv...
      • jasondk
        Thank you ruaok, & iliekcomputers :) I will incorporate your feedback and update my proposal with it soon.
      • ruaok
        I didn't finish reading yet -- I'll send you comments on monday.
      • 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.
      • Sounds good ruaok .
      • ruaok
        possibly, the timing might be hard to coordinate well.
      • 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.
      • 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.
      • 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)
      • ruaok
        good plan
      • rcombs has quit
      • Zialus_PT has quit
      • rcombs joined the channel
      • MRiddickW joined the channel