You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexey Kosenchuk (JIRA)" <ji...@apache.org> on 2018/05/07 10:10:00 UTC
[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other
parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Kosenchuk updated IGNITE-8411:
-------------------------------------
Description:
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.
- 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?
was:
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?
> 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
> Priority: Major
>
> 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.
> - 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
(v7.6.3#76005)