ValueDeserialization help requested

[Niclas Hedhman <ni...@hedhman.org>]

Paul (I guess is the only one with much clue),

Although I quite easily managed to add the feature of "object notation" (vs
the key/value notation) to map serialization, the deserialization case is
much harder to understand, and I am at loss where this decision and code
really occurs.

I have a hard time following the "flow", and wonder if the approach is
actually optimal at all. Shouldn't the input be parsed, and then create the
4 functions to feed into ValueBuildFactory.newValueBuilderWithState(), or
is that approach not possible due to some internal dependency?  Or was this
concocted before the newValueBuilderWithState() existed?

Any pointer/help is appreciated.


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: ValueDeserialization help requested

[Paul Merlin <pa...@nosphere.org>]

Paul Merlin a écrit :
> Hey Niclas,
>
> Yep, serialization is pretty straight forward.
> Deserialization is a bit more convoluted.
>
> That is to support streamed (de)serialization of large datasets like
> giant Entities/Values or large collections of these.
>
> Serialization is always streaming.
> Deserialization is streaming by default (pull parsing) but may switch to
> plain tree parsing when needed (eg. _type). This is what makes the
> deserialization a bit complex.

Some more information.

ValueDeserializerAdapter has two parameterized types:
- the pull-parsing handler
- the tree parsing node type

Pull-parsing to tree-parsing switch occurs in readObjectTree(..) method.


Niclas Hedhman a écrit :
> Although I quite easily managed to add the feature of "object notation" (vs
> the key/value notation) to map serialization, the deserialization case is
> much harder to understand, and I am at loss where this decision and code
> really occurs.

For pull-parsing this should be in:
- ValueDeserializerAdapter::deserializeMap(..)

For tree-parsing this should be in:
- ValueDeserializerAdapter::deserializeNodeEntryMap(..)
- ValueDeserializerAdapter::deserializeNodeObjectMap(..)

So, if you are speaking of MapType.Variant handling, it looks like it's
actually handled only in the tree-parsing case, not in the pull-parsing
case.

Don't hesitate to ask me for more.

Cheers

/Paul

Re: ValueDeserialization help requested

[Paul Merlin <pa...@nosphere.org>]

Hey Niclas,

Yep, serialization is pretty straight forward.
Deserialization is a bit more convoluted.

That is to support streamed (de)serialization of large datasets like
giant Entities/Values or large collections of these.

Serialization is always streaming.
Deserialization is streaming by default (pull parsing) but may switch to
plain tree parsing when needed (eg. _type). This is what makes the
deserialization a bit complex.

HTH

Cheers

/Paul


Niclas Hedhman a écrit :
> Paul (I guess is the only one with much clue),
>
> Although I quite easily managed to add the feature of "object notation" (vs
> the key/value notation) to map serialization, the deserialization case is
> much harder to understand, and I am at loss where this decision and code
> really occurs.
>
> I have a hard time following the "flow", and wonder if the approach is
> actually optimal at all. Shouldn't the input be parsed, and then create the
> 4 functions to feed into ValueBuildFactory.newValueBuilderWithState(), or
> is that approach not possible due to some internal dependency?  Or was this
> concocted before the newValueBuilderWithState() existed?
>
> Any pointer/help is appreciated.
>
>
> Cheers