the namespace is set when the timescale listenstore starts.
2021-04-19 10947, 2021
ruaok
so, my keys have namespaces set -- should be ok, no?
2021-04-19 10908, 2021
_lucifer
let me check and get back that to you
2021-04-19 10919, 2021
_lucifer
regarding str pass decode=True
2021-04-19 10927, 2021
_lucifer
what type do you want bytes or str?
2021-04-19 10932, 2021
ruaok
str
2021-04-19 10944, 2021
ruaok
but I don't really want me keys to be encoded. there is no need.
2021-04-19 10950, 2021
_lucifer
yes, then pass encode=True and decode=True
2021-04-19 10957, 2021
alastairp
encode/decode is for the value, not the key
2021-04-19 10901, 2021
alastairp
we don't encode keys any more
2021-04-19 10919, 2021
ruaok
understood, for the value.
2021-04-19 10923, 2021
_lucifer
that change will come in LB once we upgrade BU
2021-04-19 10937, 2021
_lucifer
(not encoding keys)
2021-04-19 10953, 2021
ruaok is really confused now.
2021-04-19 10913, 2021
alastairp
maybe we're talking about a few different things
2021-04-19 10922, 2021
ruaok
can one of you please tell me the correct and future proof way to set/get keys?
2021-04-19 10941, 2021
ruaok
ideally no encoded that we don't have to rescan the DB when new BU is deployed.
2021-04-19 10945, 2021
_lucifer
pass both encode and decode=True
2021-04-19 10901, 2021
ruaok
and that will currently encode my values?
2021-04-19 10919, 2021
ruaok
sot that will require a flush of all the values when the new BU comes?
2021-04-19 10921, 2021
_lucifer
yes that will correctly encode the values.
2021-04-19 10927, 2021
ruaok
(which is EXPENSIVE!)
2021-04-19 10901, 2021
_lucifer
i am not sure regarding the flush because the change is to encoding of keys not values. maybe alastairp can tell about that.
2021-04-19 10911, 2021
alastairp
no, you won't need to do anything when a new BU comes
2021-04-19 10944, 2021
ruaok
wow, this convo keeps getting worse. ;
2021-04-19 10955, 2021
_lucifer
we should prbably do the new BU upgrade soon. to avoid such confusions.
2021-04-19 10920, 2021
alastairp
the endode/decode flags are to take whatever value you pass into cache.set() and serialise it using msgpack. this means that you get out exactly what you get in
2021-04-19 10938, 2021
alastairp
this is the default and the cache has always worked like this
2021-04-19 10910, 2021
alastairp
we're not changing this behaviour in the upgrades to BU
2021-04-19 10912, 2021
ruaok
yes, but does one return str() and the other bytes() ?
2021-04-19 10905, 2021
alastairp
yes, because the redis python library returns bytes. If you don't ask it to decode the value, you get the bytes back
2021-04-19 10925, 2021
alastairp
get(..., decode=True) returns a string, get(..., decode=False) return bytes
2021-04-19 10937, 2021
ruaok
so, when the decode/encode flags go away we will always return bytes?
thanks. "github actions" shows 0 because it seems that it only tracks actions on private repos (public repos are free). Based on their docs I'd expect "Storage for actions and packages" to show our cache usage
2021-04-19 10914, 2021
alastairp
but if that shows 0 then that's fine
2021-04-19 10952, 2021
alastairp
_lucifer: I like that output!
2021-04-19 10948, 2021
ruaok
I see that brainzutils cache increment does not have the ability to increment by more than 1.
2021-04-19 10932, 2021
ruaok
I need to do that, however. should I just make multiple calls or set a new value?
2021-04-19 10906, 2021
ruaok
in theory the latter can cause a race condition, but we only have one piece of code that inserts new listens right now, so it should never happen.
2021-04-19 10911, 2021
ruaok
thoughts, alastairp, _lucifer ?
2021-04-19 10955, 2021
alastairp
mm
2021-04-19 10959, 2021
alastairp
ruaok: which method?
2021-04-19 10907, 2021
ruaok
increment
2021-04-19 10932, 2021
alastairp
I think that's a bug
2021-04-19 10937, 2021
alastairp
we should expose INCRBY
2021-04-19 10900, 2021
ruaok
that would be ideal
2021-04-19 10904, 2021
alastairp
for now, can you either loop through, or manually call cache._r.incrby?
