[jira] [Created] (IGNITE-11540) Node.js thin client: best effort affinity
Alexey Kosenchuk created IGNITE-11540: - Summary: Node.js thin client: best effort affinity Key: IGNITE-11540 URL: https://issues.apache.org/jira/browse/IGNITE-11540 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.7 Reporter: Alexey Kosenchuk Assignee: Alexey Kosenchuk Implement [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] for Node.js thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10022) JS, PHP thin clients: a more meaningful exception when ENUM type is not registered
Alexey Kosenchuk created IGNITE-10022: - Summary: JS, PHP thin clients: a more meaningful exception when ENUM type is not registered Key: IGNITE-10022 URL: https://issues.apache.org/jira/browse/IGNITE-10022 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.7 Reporter: Alexey Kosenchuk Assignee: ekaterina.vergizova NodeJS and PHP thin clients should throw a more meaningful exception for put/get ENUM type data in case the ENUM type is not registered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9465) Node.js client: improve complex object flags processing
Alexey Kosenchuk created IGNITE-9465: Summary: Node.js client: improve complex object flags processing Key: IGNITE-9465 URL: https://issues.apache.org/jira/browse/IGNITE-9465 Project: Ignite Issue Type: Bug Components: thin client Reporter: Alexey Kosenchuk Assignee: ekaterina.vergizova Fix For: 2.7 1) fix the issue in the full schema support 2) do not throw exception when object with HAS_RAW_DATA flag is received 3) support OFFSET_*_BYTE flags/optimizations when writing data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
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)
[jira] [Created] (IGNITE-8212) Binary Client Protocol spec: Key-Value Queries clarifications
Alexey Kosenchuk created IGNITE-8212: Summary: Binary Client Protocol spec: Key-Value Queries clarifications Key: IGNITE-8212 URL: https://issues.apache.org/jira/browse/IGNITE-8212 Project: Ignite Issue Type: Bug Components: documentation, thin client Affects Versions: 2.4 Reporter: Alexey Kosenchuk 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)
[jira] [Created] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
Alexey Kosenchuk created IGNITE-8039:
Summary: Binary Client Protocol spec: data types/format
clarifications
Key: IGNITE-8039
URL: https://issues.apache.org/jira/browse/IGNITE-8039
Project: Ignite
Issue Type: Bug
Components: documentation, thin client
Affects Versions: 2.4
Reporter: Alexey Kosenchuk
Assuming the Binary Client Protocol spec should be detalized enough to allow a
client development basing on the spec only, w/o looking at other client
implementations and asking additional questions...
The following should be clarified / corrected in the Binary Client Protocol
spec (v.2.4)
(https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
Type Codes table:
-
- UUID (Guid) size: should be 16 bytes, not 8 (?)
- what is Object array (type code 23) ? What is the difference between it and
Objects Wrapped In Array (type code 27) ?
- what is Collection USER_SET ?
- what is Collection USER_COL ?
- what is Collection SINGLETON_LIST ?
- Collection: misprint: should be "... + length ..."
- what is Decimal ?
- what is Timestamp ?
- what is Time ?
Complex Objects:
- what does flag USER_TYPE mean ?
- Schema "field Id; Java-style hash code of field" -> should be "... of field
name".
- "Repeat for as many times as the total number of schemas you have" -> should
be "... total number of fields you have".
- is it mandated that the number of fields in the Schema must be equal to the
number of fields in the Data Object ?
Objects Wrapped In Array
- may binary objects with different type codes be in the same array ?
- may complex objects with different type ids be in the same array ?
- "All cache operations return complex objects inside a wrapper (but not
primitives)." -> does it mean that in general a complex object (103) must
always be sent via the Binary Protocol in a wrapper (27)?
- "Byte array size" -> "Payload size" or "Size of the whole array with header" ?
- Offset. What is "object graph" here ? The Binary Protocol nowhere describes
any relations ("graph") between data objects in the protocol.
Terminology
---
Not critical but would be really convenient to define and use the same terms
along the whole spec. For example:
- "binary object" is always the same as "data object" of any type (?). Can be
"standard/predefined type object" or "complex object".
- "cluster" or "server" ?
- "cluster member" or "server nodes" ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8014) Node.js client: basic/minimal version
Alexey Kosenchuk created IGNITE-8014: Summary: Node.js client: basic/minimal version Key: IGNITE-8014 URL: https://issues.apache.org/jira/browse/IGNITE-8014 Project: Ignite Issue Type: Sub-task Components: thin client Reporter: Alexey Kosenchuk Assignee: Alexey Kosenchuk Develop the first basic/minimal version - for initial review/feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7783) Thin Client lib: PHP
Alexey Kosenchuk created IGNITE-7783: Summary: Thin Client lib: PHP Key: IGNITE-7783 URL: https://issues.apache.org/jira/browse/IGNITE-7783 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Alexey Kosenchuk Assignee: Alexey Kosenchuk Implement Thin (lightweight) Client lib in PHP programming language for Ignite Binary Client Protocol https://apacheignite.readme.io/docs/binary-client-protocol -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7782) Thin Client lib: Python
Alexey Kosenchuk created IGNITE-7782: Summary: Thin Client lib: Python Key: IGNITE-7782 URL: https://issues.apache.org/jira/browse/IGNITE-7782 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Alexey Kosenchuk Assignee: Alexey Kosenchuk Implement Thin (lightweight) Client lib in Python programming language for Ignite Binary Client Protocol https://apacheignite.readme.io/docs/binary-client-protocol -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7777) Thin Client lib: Node.js
Alexey Kosenchuk created IGNITE-: Summary: Thin Client lib: Node.js Key: IGNITE- URL: https://issues.apache.org/jira/browse/IGNITE- Project: Ignite Issue Type: New Feature Components: thin client Reporter: Alexey Kosenchuk Assignee: Alexey Kosenchuk Implement Thin (lightweight) Client lib in Node.js programming language for Ignite Binary Client Protocol https://apacheignite.readme.io/docs/binary-client-protocol Examples of other Thin Clients: .net https://github.com/apache/ignite/tree/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Client java https://github.com/gridgain/apache-ignite/tree/ignite-7421/modules/thinclient Scope of work - Functionality: Support all operations of the Ignite Binary Client Protocol 2.4. Support name/password authentication - TBD (not in the protocol yet). Support optional SSL/TLS communication - TBD (not in the protocol yet). Support optional failover/reconnect - TBD. Minimal Node.js version - TBD. Synch ops emulation - callbacks, or Promises, or asynch/await - TBD. Examples: Cover all basic features - Key-value API, SQL, Scan queries, Cluster configuration/management, Authentication, SSL/TLS. Tests: Jasmine tests for all API methods and all basic features. Simple Jasmine tests to start examples. How to emulate node failure to test failover/reconnect? - TBD. Docs: Auto-generated API spec from comments. JSdoc, or javadoc, or what? - TBD. Readme for the lib. Simple instruction to setup/run examples. Simple instruction to setup/run Jasmine tests. Docs format - .md in the repo, or dash.readme.io ? - TBD. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
