[
https://issues.apache.org/jira/browse/IGNITE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702069#comment-16702069
]
Igor Sapego commented on IGNITE-8212:
-------------------------------------
[~Artem Budnikov], see my comment below:
1. I like how you give a reference to a javadoc for some operations, but why
don't do that for all operations?
2. Maybe it makes sense to give reference for a Header field format in every
description of this field? It can help, if person is not reading the whole page
from the beginning and just want to find out a format of the one specific
message.
3. Maybe it makes sense to mention in the beginning of the page that standard
field types like "int", "byte" and others are described in "Data format"
section.
> 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 cache.
> - 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.
> - OP_CACHE_GET_AND_REPLACE:
> -- "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
> - OP_CACHE_CLEAR_XXX and OP_CACHE_REMOVE_XXX:
> -- 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 spec?
> -- (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 intentional?
> -- 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
(v7.6.3#76005)
