[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications

["Igor Sapego (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Sapego updated IGNITE-8411:
--------------------------------
    Fix Version/s:     (was: 2.8)
                   2.9

> Binary Client Protocol spec: other parts clarifications
> -------------------------------------------------------
>
>                 Key: IGNITE-8411
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8411
>             Project: Ignite
>          Issue Type: Improvement
>          Components: documentation, thin client
>    Affects Versions: 2.4
>            Reporter: Alexey Kosenchuk
>            Assignee: Igor Sapego
>            Priority: Major
>             Fix For: 2.9
>
>
> issues against previous parts: IGNITE-8039 IGNITE-8212
> Cache Configuration
>  -------------------
>  [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations]
>  - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - QueryEntity - Structure of QueryField:
>  absent "default value - type Object" - it is the last field of the QueryField in reality.
>  - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration:
>  Absent CacheAtomicityMode - is the first field in reality.
>  Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and MaxQueryIterators in reality.
>  "Invalidate" field - does not exist in reality.
>  - meaning and possible values of every configuration parameter must be clarified. If clarified in other docs, this spec must have link(s) to that docs.
>  - suggest to combine somehow Cache Configuration descriptions in OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid duplicated descriptions.
> SQL and Scan Queries
>  --------------------
>  [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations]
>  - "Flag. Pass 0 for default, or 1 to keep the value in binary form.":
>  "the value in binary form" flag should be left end clarified in the operations to which it is applicable for.
>  - OP_QUERY_SQL:
>  most of the fields in the request must be clarified. If clarified in other docs, this spec must have link(s) to that docs.
>  For example:
>  ** "Name of a type or SQL table": name of what type?
>  - OP_QUERY_SQL_FIELDS:
>  most of the fields in the request must be clarified. If clarified in other docs, this spec must have link(s) to that docs.
>  For example:
>  ** is there any correlation between "Query cursor page size" and "Max rows"?
>  ** "Statement type": why there are only three types? what about INSERT, etc.?
>  - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. But responses for all other query operations contain it. Is it intentional?
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality.
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type "long". Should be "int".
>  - OP_QUERY_SCAN:
>  format and rules of the Filter object must be clarified. If clarified in other docs, this spec must have link(s) to that docs.
>  - OP_QUERY_SCAN:
>  in general, it's not clear how this operation should be supported on platforms other than the mentioned in "Filter platform" field.
>  - OP_QUERY_SCAN: "Number of partitions to query"
>  Should be updated to "A partition number to query"
>  
> Binary Types
>  ------------
>  [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations]
>  - somewhere should be explained when and why these operations need to be supported by a client.
>  - Type id and Field id:
>  should be clarified that before an Id calculation Type and Field names must be updated to low case.
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id:
>  in reality it is not a type id (hash code) but a type code (1, 2,... 10,... 103,...).
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name":
>  should be explained what is it. If explained in other docs, this spec must have link(s) to that docs.
>  - OP_PUT_BINARY_TYPE - schema id:
>  mandatory algorithm of schema Id calculation must be described somewhere. If described in other docs, this spec must have link(s) to that docs.
>  - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME:
>  should be explained when and why these operations need to be supported by a client.
>  How this operation should be supported on platforms other than the mentioned in "Platform id" field.
>  - OP_REGISTER_BINARY_TYPE_NAME:
>  Type name - is it "full" or "short" name here?
>  Type id - is it a hash from "full" or "short" name here?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)