ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Sapego (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
Date Thu, 29 Nov 2018 13:19:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16703148#comment-16703148

Igor Sapego commented on IGNITE-8212:

Looks good. [~dmagda] or [~pgarg], can you take a look for a final review? Here is the link:

> Binary Client Protocol spec: Key-Value Queries clarifications
> -------------------------------------------------------------
>                 Key: IGNITE-8212
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8212
>             Project: Ignite
>          Issue Type: Improvement
>          Components: documentation, thin client
>    Affects Versions: 2.4
>            Reporter: Alexey Kosenchuk
>            Assignee: Artem Budnikov
>            Priority: Major
>             Fix For: 2.7
> https://apacheignite.readme.io/v2.4/docs/binary-client-protocol-key-value-operations
> - all operations - "Flag. Pass 0 for default, or 1 to keep the value in binary form":
> -- remove words about binary form and keep "Pass 0 for default" for all operations where
this flag has no meaning.
> -- clarify about binary form in operations where it has a meaning.
> - OP_CACHE_GET: clarify that null is returned if the provided key does not exist in the
> - OP_CACHE_GET_AND_PUT: clarify that new entry is created, if the provided key does not
exist in the cache, and null is returned in this case.
> -- "if and only if there is a value currently mapped for that key" - is confusing. Is
it possible that an existing key has no associated value? Suggest to rephrase as "if and only
if the key exists in the cache"
> -- clarify that null is returned if the key does not exist in the cache.
> - OP_CACHE_GET_AND_REMOVE: clarify that null is returned if the key does not exist in
the cache.
> - OP_CACHE_PUT_IF_ABSENT: clarify what is "Success Flag" - true if the new entry is created,
false if the specified key already exists in the cache.
> - OP_CACHE_GET_AND_PUT_IF_ABSENT: "Previously contained value regardless of whether put
happened or not" - is confusing. Suggest to rewrite "the current value associated with the
key if it already exists in the cache, null if the new entry is created".
> - OP_CACHE_GET_SIZE: clarify Peek modes
> -- what is the difference between the corresponding operations? Only in notifying / not
notifying listeners and cache writers? Or there are other differences not clarified by the
> -- (the operations could be combined in one set - with a flag required/not required notifications)
> -- there is OP_CACHE_REMOVE_IF_EQUALS. But there is no OP_CACHE_CLEAR_IF_EQUALS. Is it
> -- OP_CACHE_REMOVE_KEY and OP_CACHE_REMOVE_IF_EQUALS have "Value indicating whether remove
happened" in the response. But OP_CACHE_CLEAR_KEY does not have such a flag in the response.
Is it intentional?
> -- OP_CACHE_CLEAR_KEYS, OP_CACHE_REMOVE_KEYS: clarify that even if some of the specified
keys do not exist other entries are removed anyway.

This message was sent by Atlassian JIRA

View raw message