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
