Niclas,
As you found out, NamedAssociation serialized form is the same as for Maps.
I recall that the use of arrays of key/value objects was choosen to keep
entries order as JSON do not guarantee keys order.
/Paul
Niclas Hedhman a écrit :
> I have been looking at this issue and I wonder if there are any notes from
> the original implementation...
>
> For instance, a regular Map is serialized to
> map: [
> { "key" : "FirstName", "value" : "Niclas" },
> { "key" : "LastName", "value" : "Hedhman" }
> ]
> but it could have been made;
>
> map : {
> "FirstName" : "Niclas",
> "LastName" : "Hedhman"
> }
>
> My guess is that there is "schema" reasons for this. Also, it is not
> something that can now be changed, at least not without adding built-in
> handing of old format (which is a possibility).
>
> One of the usecases of this outside of the storage, would be using this
> serialization SPI for the toValue() and toEntity() methods, in which case
> the serialization would end up being processable in JavaScript.
>
> So, in that case, would it makes more sense to have "key"/"value", or to
> have Maps showing up as objects?? I am not that fluent in JavaScript to
> have an opinion. I can imagine that having the second/object form, is neat
> when one knows what is coming over the wire, but could messy to iterate as
> built-in attributes need to be filtered out. Or?
>
>
> // Niclas
>
> On Thu, May 21, 2015 at 7:55 AM, Niclas Hedhman <[email protected]> wrote:
>
>> Jiri,
>> thanks for your analysis of why it breaks.
>>
>> I assume that a JSON Object for NamedAssociation is the correct path
>> forward,
>>
>> {
>> "left" : "723470239476",
>> "right" : "109874275692"
>> }
>>
>> instead of the JSON Array which needs inner objects in that case,
>>
>> [
>> { "left" : "723470239476" },
>> { "right" : "109874275692" }
>> ]
>>
>> Paul, your thoughts?
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>
