[jira] [Comment Edited] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458790#comment-16458790
]
Alexey Kosenchuk edited comment on IGNITE-8039 at 4/30/18 8:06 PM:
---
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- Time: "since midnight" in what timezone?
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- If "element" in Data Array has "type code" field, then it's size should be
{{length}} * 9. The same for other similar arrays.
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
was (Author: alexey.kosenchuk):
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- Time: should be clarified it's UTC (?)
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- If "element" in Data Array has "type code" field, then it's size should be
{{length}} * 9. The same for other similar arrays.
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
> 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: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> 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 i
[jira] [Comment Edited] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458790#comment-16458790
]
Alexey Kosenchuk edited comment on IGNITE-8039 at 4/30/18 7:59 PM:
---
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- Time: should be clarified it's UTC (?)
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- If "element" in Data Array has "type code" field, then it's size should be
{{length}} * 9. The same for other similar arrays.
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
was (Author: alexey.kosenchuk):
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- If "element" in Data Array has "type code" field, then it's size should be
{{length}} * 9. The same for other similar arrays.
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
> 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: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> 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 di
[jira] [Comment Edited] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458790#comment-16458790
]
Alexey Kosenchuk edited comment on IGNITE-8039 at 4/30/18 6:37 PM:
---
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- If "element" in Data Array has "type code" field, then it's size should be
{{length}} * 9. The same for other similar arrays.
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
was (Author: alexey.kosenchuk):
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
> 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: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> 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_LIS
[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458790#comment-16458790
]
Alexey Kosenchuk commented on IGNITE-8039:
--
[~isapego] thanks.
About the general format - it's better if [~dmagda] / [~vozerov] will confirm
how the spec should be formatted and where located.
Might be better if the types are grouped/ordered not by type code but by their
kind - primitive types and their arrays first; then
string/date/time/.../decimal/enum/...; collections/map/object_array at the end.
Comments:
- Byte: should be mentioned it's signed (?)
- Short, Int, Long: should be mentioned it's little-endian (?)
- Float, Double: should be mentioned it corresponds to the IEEE 754
floating-point numbers
- Decimal: just curious why "data" here is in big-endian while in general
"Ignite binary client protocol has little-endian byte ordering".
- Enum: it's format should be clarified.
** "type_id" is an id of the enum type registered by OP_PUT_BINARY_TYPE
command?
** "ordinal" is a position (starting from 0?) of a field in the enum type
registered by OP_PUT_BINARY_TYPE command??
- arrays: as we see from Java client implementation there are two formats of
arrays:
1) where every "element" does not have "type code" field but only "value". For
example Byte array, Int array, etc.
2) where every "element" has both - "type code" and "value" fields. For
example Date array, String array, etc.
This should be clarified, at least.
And may be unified (?)
- Collection, Map, Object array: should be better explained objects of which
types they may include. Absolutely any mentioned in this doc? I.e. it may be a
Collection of Maps, a Collection of Object arrays, a Collection of Collections,
etc.? And the same for Map? And the same for Object array?
> 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: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> 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] [Commented] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception
[
https://issues.apache.org/jira/browse/IGNITE-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458717#comment-16458717
]
Maxim Muzafarov commented on IGNITE-8158:
-
[~Sergey Nuyanzin],
Hello, feel free to assign this issue for youself, sure!
>From my point of view, it's not enough only log exceptions. We should perform
>all cleanups and fail whole test-case.
Note, that afterTestsStopped method can make additional checks using class
resources, so we can't perform cleanups earlier.
> Missed cleanups if afterTestsStop throws exception
> --
>
> Key: IGNITE-8158
> URL: https://issues.apache.org/jira/browse/IGNITE-8158
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Priority: Minor
> Labels: newbie, test
> Fix For: 2.6
>
>
> Method {{afterTestsStopped}} might throw exception. Contibutor should provide
> solution for ensuring that all cleanups in {{tearDown}} method would be
> executed in this case.
> {code:java|title=GridAbstractTest.java}
> /** {@inheritDoc} */
> @Override protected void tearDown() throws Exception {
> ...
> try {
> afterTest();
> }
> finally {
> serializedObj.clear();
> if (isLastTest()) {
> ...
> afterTestsStopped();
> if (startGrid)
> G.stop(getTestIgniteInstanceName(), true);
> // Remove counters.
> tests.remove(getClass());
> // Remove resources cached in static, if any.
> GridClassLoaderCache.clear();
> U.clearClassCache();
> MarshallerExclusions.clearCache();
> BinaryEnumCache.clear();
> }
> Thread.currentThread().setContextClassLoader(clsLdr);
> clsLdr = null;
> cleanReferences();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8425) .NET: IIgnite.GetMultimap
[ https://issues.apache.org/jira/browse/IGNITE-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-8425: --- Issue Type: New Feature (was: Task) > .NET: IIgnite.GetMultimap > - > > Key: IGNITE-8425 > URL: https://issues.apache.org/jira/browse/IGNITE-8425 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Add multimap API to .NET, see IGNITE-640. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8425) .NET: IIgnite.GetMultimap
[ https://issues.apache.org/jira/browse/IGNITE-8425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-8425: --- Issue Type: Task (was: Bug) > .NET: IIgnite.GetMultimap > - > > Key: IGNITE-8425 > URL: https://issues.apache.org/jira/browse/IGNITE-8425 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Add multimap API to .NET, see IGNITE-640. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8425) .NET: IIgnite.GetMultimap
Pavel Tupitsyn created IGNITE-8425: -- Summary: .NET: IIgnite.GetMultimap Key: IGNITE-8425 URL: https://issues.apache.org/jira/browse/IGNITE-8425 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Add multimap API to .NET, see IGNITE-640. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
