[
https://issues.apache.org/jira/browse/IGNITE-15944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479114#comment-17479114
]
Roman Puchkovskiy edited comment on IGNITE-15944 at 1/20/22, 6:37 AM:
----------------------------------------------------------------------
One more problem.
h3. Avoiding to write a descriptor ID for 'effectively final' fields
We can avoid writing such descriptor ID only when we know for sure how to
deserialize any possible value (of the given type).
For primitives it's easy: just the value needs to be written.
For non-primitives we must take into account the possibility to have a null.
This means that we still need to write a discriminator that will allow us to
reconstruct the situation during unmarshalling: was it null or not. So the
example in the spec (last line of it, namely
{\{0, null // child2 is Child2 with field1 and field 3 }}
) will not work: we'll need a null marker in the beginning of this sequence.
This can be solved if we add a built-in 'type' like NOT_NULL. For the cases
when we know the concrete type for sure (those that are named 'effectively
final' types in the spec), and the type is referential (i.e. non-primitive),
we'll write either descriptor ID of NULL (for null) or that NOT_NULL marker
(for a non-null reference) instead of writing the real type descriptor ID. In
the worst case (when type descriptor ID is below 255 and can be written using
one byte) we'll not save any space. But in cases when the type descriptor ID is
over 255 (and requires at least 3 bytes to write), we'll spare 2 bytes.
was (Author: rpuch):
One more problem.
h2. Avoiding to write a descriptor ID for 'effectively final' fields
We can avoid writing such descriptor ID only when we know for sure how to
deserialize any possible value (of the given type).
For primitives it's easy: just the value needs to be written.
For non-primitives we must take into account the possibility to have a null.
This means that we still need to write a discriminator that will allow us to
reconstruct the situation during unmarshalling: was it null or not. So the
example in the spec (last line of it, namely
{{0, null // child2 is Child2 with field1 and field 3 }}
) will not work: we'll need a null marker in the beginning of this sequence.
This can be solved if we add a built-in 'type' like NOT_NULL. For the cases
when we know the concrete type for sure (those that are named 'effectively
final' types in the spec), and the type is referential (i.e. non-primitive),
we'll write either descriptor ID of NULL (for null) or that NOT_NULL marker
(for a non-null reference) instead of writing the real type descriptor ID. In
the worst case (when type descriptor ID is below 255 and can be written using
one byte) we'll not save any space. But in cases when the type descriptor ID is
over 255 (and requires at least 3 bytes to write), we'll spare 2 bytes.
> [Networking] User object serialization
> --------------------------------------
>
> Key: IGNITE-15944
> URL: https://issues.apache.org/jira/browse/IGNITE-15944
> Project: Ignite
> Issue Type: Epic
> Reporter: Semyon Danilov
> Priority: Major
> Labels: iep-67, ignite-3
> Fix For: 3.0.0-alpha5
>
>
> Arbitrary objects serialization must be provided by Apache Ignite. Unlike
> {{NetworkMessage}} descendants, user objects are not known to the system in
> advance, and serialization layout must be resolved at runtime.
> For more information look at the
> https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
