Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Message-ID: <55A7D290.306@nosphere.org>
Date: Thu, 16 Jul 2015 17:49:36 +0200
From: Paul Merlin <paul@nosphere.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@zest.apache.org
Subject: Re: Deserialization of Arrays
References: 
 <CADmm+Ke20iSctiJ_2t3J44NQjDQHgdS1t1+jx1+22y+DAaieJQ@mail.gmail.com>
 <55A7D06D.5020109@nosphere.org>
In-Reply-To: <55A7D06D.5020109@nosphere.org>
Content-Type: multipart/alternative;
 boundary="------------080004020002050603020809"

--------------080004020002050603020809
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Paul Merlin a =C3=A9crit :
> Niclas Hedhman a =C3=A9crit :
>> 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 =C3=A9crit :
> I would like to fix that the Arrays are serialized "correctly", but sti=
ll
> do it via "Serialization Variants" (as is coming in effect for Maps), s=
o
> 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 t=
hat
> 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

=20

--------------080004020002050603020809--