You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polygene.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2015/07/16 16:25:18 UTC
Deserialization of Arrays
I think that the "Array"-case at root level was effectively ignored in the
current ValueSerialization system.
In ValueDeserializerAdapter.deserializeRoot() there is the following code;
if( type.isArray() )
{
Scanner scanner = new Scanner( input, UTF_8 ).useDelimiter( "\\A" );
if( !scanner.hasNext() )
{
return null;
}
String string = scanner.next();
return (T) deserializeBase64Serialized( string );
}
which clearly goes "well, I have no strength to figure this out, so do Java
serialization". Likewise, theValueSerializerAdapter.serializeRoot() does;
else if( object.getClass().isArray() )
{
// Array Value
output.write( serializeBase64Serializable( object ).getBytes( UTF_8 ) );
}
But this is just silly, as it won't handle ValueComposites.
Using List instead introduces the problem that it is not type-specific
enough for the deserialization to take place, although I think it works ok
for serialization.
I also think that the same happens when array is serialized/deserialized
anywhere else, which would then affect all stored data.
I would like to fix that the Arrays are serialized "correctly", but still
do it via "Serialization Variants" (as is coming in effect for Maps), so
that the current behavior can remain default, and that 3.0 switches the
default, and allow the legacy way to be declared to be used instead.
If that is acceptable, I am a bit shaky on the code in deserialization
case, due to the 'streaming' case and will probably need help to sort that
out.
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: Deserialization of Arrays
Posted by Paul Merlin <pa...@nosphere.org>.
Finally found historical discussion about this :
https://groups.google.com/forum/#!msg/qi4j-dev/kp9dgsc3O1A/i4rNI_64tbUJ
Re: Deserialization of Arrays
Posted by Paul Merlin <pa...@nosphere.org>.
Paul Merlin a écrit :
> Niclas Hedhman a écrit :
>> I think that the "Array"-case at root level was effectively ignored in the
>> current ValueSerialization system.
> Yup, during the 2.0 rewrite of serialization I kept the serialization
> backward compatible and arrays are one of thoses cases ...
>
> Moreover, Property<"SomeArrayType"> support is itself flakky.
> For example it fails at equality tests.
>
> See:
> - Absence of []s in ValueEqualityTest.java
> - Absence of []s in PropertyEqualityTest.java
> - Comments in AbstractValueCompositeSerializationTest.java#L188
>
> There's PropertyStringArrayTest.java but it does not cover much.
>
> This raised the very question of supporting []s in the past.
To add to that.
We have *no* []'s in the model used to test query engines.
See `org.qi4j.test.indexing.model` package in core/testsupport.
Finally, even arrays of "primitive types" bring in some complexity: if
String[] or int[] could be treated as collections, byte[] should not,
most of the time ...
Niclas Hedhman a écrit :
> I would like to fix that the Arrays are serialized "correctly", but still
> do it via "Serialization Variants" (as is coming in effect for Maps), so
> that the current behavior can remain default, and that 3.0 switches the
> default, and allow the legacy way to be declared to be used instead.
>
> If that is acceptable, I am a bit shaky on the code in deserialization
> case, due to the 'streaming' case and will probably need help to sort that
> out.
Once and if we settle on a way to support arrays properties, this looks
like the way to go. I'll help for the streaming deserialization
implementation.
/Paul
Re: Deserialization of Arrays
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas,
Niclas Hedhman a écrit :
> I think that the "Array"-case at root level was effectively ignored in the
> current ValueSerialization system.
Yup, during the 2.0 rewrite of serialization I kept the serialization
backward compatible and arrays are one of thoses cases ...
Moreover, Property<"SomeArrayType"> support is itself flakky.
For example it fails at equality tests.
See:
- Absence of []s in ValueEqualityTest.java
- Absence of []s in PropertyEqualityTest.java
- Comments in AbstractValueCompositeSerializationTest.java#L188
There's PropertyStringArrayTest.java but it does not cover much.
This raised the very question of supporting []s in the past.
/Paul