-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add reading & writing of flags #18
Conversation
👀 Tests passed, but builds failed? |
|
Thanks @ananthakumaran. I didn't notice it was running that. Have |
Bump @ananthakumaran |
sorry for the delay. I am kind of reluctant about merging patches that add the ability to read/write flags. There are two aspects, 1) I haven't given much thought to flags during the initial implementation which makes it hard to retrofit. 2) There aren't many use cases which require the flags. I don't want a situation where you finish the PR, but I decide not to merge because of the above reasons. With that said, here are my thoughts. I don't like to attach meaning to flag (aka bit 1 is serialized, bit 2 is compressed, etc). As the flag page indicates this is different across language bindings. What I would instead like is, just expose it via the coder. encode(any, options :: Keyword.t()) :: iodata
encode(any, options :: Keyword.t()) :: {flag :: binary, iodata} @callback decode(iodata, options :: Keyword.t()) :: any
@callback decode(iodata, flag :: binary, options :: Keyword.t()) :: any basically, encode can return I am torn about the changes in |
@ananthakumaran It seems that you are not eager to merge this PR as it is. Are you willing to reconsider it or would you like to see a different approach being taken here so we can eventually have the flags functionality in place? |
Could you explain your use case? I am not very eager at this point, but
that would change if more people want this
…On Tue, Jun 4, 2019, 7:23 AM Stefan Slaveykov ***@***.***> wrote:
@ananthakumaran <https://github.com/ananthakumaran> It seems that you are
not eager to merge this PR as it is. Are you willing to reconsider it or
would you like to see a different approach being taken here so we can
eventually have the flags functionality in place?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18?email_source=notifications&email_token=AABEN5WEBHK4ARMLAT4NUJTPYXDH5A5CNFSM4G37KPKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3FKDI#issuecomment-498488589>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABEN5XYIEDJHDGZQ6ACFILPYXDH5ANCNFSM4G37KPKA>
.
|
Closing due to no movement. |
Adds reading and writing of flags to achieve compatibility with Dalli (ruby client). Fixes #7. Takes inspiration from #8 and expands on comments.
flags
option toMemcache.xxx
functions that take options.:serialised
,:compressed
flags (0x1, 0x2 respectively)encode_flags
callback forCoder
s with a default passthrough impl.:serialised
flag to theJSON
Coder
.There are some slightly breaking changes here, but the core API (
Memcache
module) is not affected.Memcache.Connection.execute/4
andMemcache.Connection.execute_quiet/2
directly will give results back in a different format, potentially;{:ok, value :: any, flags :: keyword}
instead of{:ok, value :: any}
. I'm pretty sure it's impossible to add flag support without this change, unfortunately.Coder
s should nowuse Memcache.Coder
rather than@behaviour use Memcache.Coder
and optionally implementencode_flags/2
.