[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441523#comment-16441523
]
Alexey Kosenchuk edited comment on IGNITE-8039 at 4/23/18 8:17 PM:
-------------------------------------------------------------------
Few more comments (additional to the mentioned above) - really critical to
understand the format of complex objects:
- HAS_SCHEMA flag should be clarified. Better to call it HAS_SCHEMA_ID.
- COMPACT_FOOTER flag should be clarified (currently not in the spec at all).
- Should be clarified there are two formats of the footer:
-- the footer contains the offsets only - this is the actual option which
should be used (it is not described in the current spec at all).
-- the footer contains the field Ids and the offsets - this it the deprecated
option (?)
- Should be clarified that offsets may be not only Integer but Byte or Short
as well. Flags OFFSET_ONE_BYTE, OFFSET_TWO_BYTES are missed in the current spec.
- The mandatory algorithm of the Schema Id calculation should be described
somewhere.
Also,
- Should be clarified that for a hash calculation Field Name and Type Name
need to be updated to low case. Cache Name should not.
was (Author: alexey.kosenchuk):
Few more comments (additional to the mentioned above) - really critical to
understand the format of complex objects:
- HAS_SCHEMA flag should be clarified. Better to call it HAS_SCHEMA_ID:
-- if the flag is set, then the Schema Id is specified and the Schema contains
the offsets only (?) - this is the actual option which should be used.
-- if the flag is not set, then the Schema Id is ignored and the Schema
contains the field Ids and the offsets - this it the deprecated option (?)
- The mandatory algorithm of the Schema Id calculation should be described
somewhere.
> 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
> Assignee: Vladimir Ozerov
> Priority: Major
> Fix For: 2.6
>
>
> 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)
