-
Notifications
You must be signed in to change notification settings - Fork 21
Add reading & writing of flags #18
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
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()) :: anybasically, 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.
flagsoption toMemcache.xxxfunctions that take options.:serialised,:compressedflags (0x1, 0x2 respectively)encode_flagscallback forCoders with a default passthrough impl.:serialisedflag to theJSONCoder.There are some slightly breaking changes here, but the core API (
Memcachemodule) is not affected.Memcache.Connection.execute/4andMemcache.Connection.execute_quiet/2directly 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.Coders should nowuse Memcache.Coderrather than@behaviour use Memcache.Coderand optionally implementencode_flags/2.