ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Kosenchuk (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
Date Fri, 27 Apr 2018 11:46:00 GMT
Alexey Kosenchuk created IGNITE-8411:
----------------------------------------

             Summary: Binary Client Protocol spec: other parts clarifications
                 Key: IGNITE-8411
                 URL: https://issues.apache.org/jira/browse/IGNITE-8411
             Project: Ignite
          Issue Type: Bug
          Components: documentation, thin client
    Affects Versions: 2.4
            Reporter: Alexey Kosenchuk


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 - Row count field: says type "long". But Row count
field in responses for all other query operations is "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.

 

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
(v7.6.3#76005)

Mime
View raw message