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/05/21 01:55:13 UTC
ZEST-23
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
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Fri, May 22, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org> wrote:
>
> Otherwise, regarding ZEST-22 related changes, given the comments I
> already made in another thread (toValue() & toEntity()), I only have one
> remark: could we get rid of the suspicious cast in
> EntityBuilderInstance#L95 : (FunctionStateResolver) ?
>
Ok, there are two calls to EntityBuilderInstance constructor, one with null
and the other with the FunctionStateResolver, so I changed the constructor
signature. Not committed yet...
Thanks for look into this. Increases my confidence a bit.
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> @Paul,
> since you are the most familiar with the serialization system, could you
> take a look at the ZEST-22_toEntity-toValue branch?
Ok, reviewed changes presents in the ZEST-22_toEntity-toValuebranch.
All tests pass.
Changes related to NamedAssociation serialization as entries-array or
plain-object (ZEST-23) look good to me! Plus you introduced MapType
variant which should pave the way for the future change for Map
serialization. Nice.
> There is a very absurd change in AssociationTest, which was complaining
> that the friend() method wasn't Optional and not set in the testcase for
> "Rickard". So, it should have been failing all the while, and no idea why
> that wasn't happening before, and why my changes would have any effect on
> this...
Looks like you accidentally removed @Optional in 5915625 and put it back
in e6d2d6b.
Otherwise, regarding ZEST-22 related changes, given the comments I
already made in another thread (toValue() & toEntity()), I only have one
remark: could we get rid of the suspicious cast in
EntityBuilderInstance#L95 : (FunctionStateResolver) ?
Cheers
/Paul
Re: ZEST-23
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> @Paul,
> since you are the most familiar with the serialization system, could you
> take a look at the ZEST-22_toEntity-toValue branch?
>
> There is a very absurd change in AssociationTest, which was complaining
> that the friend() method wasn't Optional and not set in the testcase for
> "Rickard". So, it should have been failing all the while, and no idea why
> that wasn't happening before, and why my changes would have any effect on
> this...
Good someone else put his eyes/hands on/in this code !
I'll review the changes tomorrow.
'nite
/Paul
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
:-( Obviously too tired. The change went into the wrong branch... darn...
well... The above branch is where the changes went.
On Thu, May 21, 2015 at 10:36 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> @Paul,
> since you are the most familiar with the serialization system, could you
> take a look at the ZEST-22_toEntity-toValue branch?
>
> There is a very absurd change in AssociationTest, which was complaining
> that the friend() method wasn't Optional and not set in the testcase for
> "Rickard". So, it should have been failing all the while, and no idea why
> that wasn't happening before, and why my changes would have any effect on
> this...
>
>
>
> On Thu, May 21, 2015 at 6:45 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
>> Yes... What I just committed into a separate branch did the pther way
>> around. I'll make the other one after dinner.
>>
>> On Thu, May 21, 2015 at 6:29 PM, Kent Sølvsten <ke...@gmail.com>
>> wrote:
>>
>>> b. Keep the Map serialization for now as it is.
>>> c. Plan the change for 3.0 later in the year, giving us a bit of time
>>> to
>>> figure out the migration.
>>>
>>>
>>> Agreed
>>>
>>> a. Change NamedAssociation to be serialized in "object" form now.
>>>
>>> You mean change the deserializer to expect object form, right?
>>>
>>> /Kent
>>>
>>>
>>> Den 21-05-2015 kl. 12:25 skrev Paul Merlin:
>>> > Niclas Hedhman a écrit :
>>> >> On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org>
>>> wrote:
>>> >>> Looking at it today I don't know why key order should matter.
>>> >>> I'd say that having more idiomatic JSON would make usage less
>>> contrived,
>>> >>> which would be a good thing.
>>> >> I agree that is very desirable, and it is now mostly a matter of how
>>> to
>>> >> handle data migration, if we go with Kent's advice.
>>> >>
>>> >> Obviously no one uses NamedAssociation, since I can't see that this
>>> ever
>>> >> worked, as there is a mismatch (serialize object and deserialize an
>>> array)
>>> >> at the moment.
>>> >>
>>> >> Kent, good to know that JS is cool with that.
>>> >>
>>> >> The quickest fix was to change the Serializer to match the
>>> Deserializer for
>>> >> NamedAssociations. And I am committing that version shortly in a
>>> separate
>>> >> branch...
>>> >>
>>> >> But, while discussing this, I think we should do this;
>>> >>
>>> >> a. Change NamedAssociation to be serialized in "object" form now.
>>> >> b. Keep the Map serialization for now as it is.
>>> >> c. Plan the change for 3.0 later in the year, giving us a bit of
>>> time to
>>> >> figure out the migration.
>>> >>
>>> >> WDYT?
>>> > Sounds like a good plan.
>>> >
>>> >
>>>
>>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
@Paul,
since you are the most familiar with the serialization system, could you
take a look at the ZEST-22_toEntity-toValue branch?
There is a very absurd change in AssociationTest, which was complaining
that the friend() method wasn't Optional and not set in the testcase for
"Rickard". So, it should have been failing all the while, and no idea why
that wasn't happening before, and why my changes would have any effect on
this...
On Thu, May 21, 2015 at 6:45 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Yes... What I just committed into a separate branch did the pther way
> around. I'll make the other one after dinner.
>
> On Thu, May 21, 2015 at 6:29 PM, Kent Sølvsten <ke...@gmail.com>
> wrote:
>
>> b. Keep the Map serialization for now as it is.
>> c. Plan the change for 3.0 later in the year, giving us a bit of time to
>> figure out the migration.
>>
>>
>> Agreed
>>
>> a. Change NamedAssociation to be serialized in "object" form now.
>>
>> You mean change the deserializer to expect object form, right?
>>
>> /Kent
>>
>>
>> Den 21-05-2015 kl. 12:25 skrev Paul Merlin:
>> > Niclas Hedhman a écrit :
>> >> On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org>
>> wrote:
>> >>> Looking at it today I don't know why key order should matter.
>> >>> I'd say that having more idiomatic JSON would make usage less
>> contrived,
>> >>> which would be a good thing.
>> >> I agree that is very desirable, and it is now mostly a matter of how to
>> >> handle data migration, if we go with Kent's advice.
>> >>
>> >> Obviously no one uses NamedAssociation, since I can't see that this
>> ever
>> >> worked, as there is a mismatch (serialize object and deserialize an
>> array)
>> >> at the moment.
>> >>
>> >> Kent, good to know that JS is cool with that.
>> >>
>> >> The quickest fix was to change the Serializer to match the
>> Deserializer for
>> >> NamedAssociations. And I am committing that version shortly in a
>> separate
>> >> branch...
>> >>
>> >> But, while discussing this, I think we should do this;
>> >>
>> >> a. Change NamedAssociation to be serialized in "object" form now.
>> >> b. Keep the Map serialization for now as it is.
>> >> c. Plan the change for 3.0 later in the year, giving us a bit of
>> time to
>> >> figure out the migration.
>> >>
>> >> WDYT?
>> > Sounds like a good plan.
>> >
>> >
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
Yes... What I just committed into a separate branch did the pther way
around. I'll make the other one after dinner.
On Thu, May 21, 2015 at 6:29 PM, Kent Sølvsten <ke...@gmail.com>
wrote:
> b. Keep the Map serialization for now as it is.
> c. Plan the change for 3.0 later in the year, giving us a bit of time to
> figure out the migration.
>
>
> Agreed
>
> a. Change NamedAssociation to be serialized in "object" form now.
>
> You mean change the deserializer to expect object form, right?
>
> /Kent
>
>
> Den 21-05-2015 kl. 12:25 skrev Paul Merlin:
> > Niclas Hedhman a écrit :
> >> On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org> wrote:
> >>> Looking at it today I don't know why key order should matter.
> >>> I'd say that having more idiomatic JSON would make usage less
> contrived,
> >>> which would be a good thing.
> >> I agree that is very desirable, and it is now mostly a matter of how to
> >> handle data migration, if we go with Kent's advice.
> >>
> >> Obviously no one uses NamedAssociation, since I can't see that this ever
> >> worked, as there is a mismatch (serialize object and deserialize an
> array)
> >> at the moment.
> >>
> >> Kent, good to know that JS is cool with that.
> >>
> >> The quickest fix was to change the Serializer to match the Deserializer
> for
> >> NamedAssociations. And I am committing that version shortly in a
> separate
> >> branch...
> >>
> >> But, while discussing this, I think we should do this;
> >>
> >> a. Change NamedAssociation to be serialized in "object" form now.
> >> b. Keep the Map serialization for now as it is.
> >> c. Plan the change for 3.0 later in the year, giving us a bit of time
> to
> >> figure out the migration.
> >>
> >> WDYT?
> > Sounds like a good plan.
> >
> >
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Kent Sølvsten <ke...@gmail.com>.
b. Keep the Map serialization for now as it is.
c. Plan the change for 3.0 later in the year, giving us a bit of time to
figure out the migration.
Agreed
a. Change NamedAssociation to be serialized in "object" form now.
You mean change the deserializer to expect object form, right?
/Kent
Den 21-05-2015 kl. 12:25 skrev Paul Merlin:
> Niclas Hedhman a écrit :
>> On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org> wrote:
>>> Looking at it today I don't know why key order should matter.
>>> I'd say that having more idiomatic JSON would make usage less contrived,
>>> which would be a good thing.
>> I agree that is very desirable, and it is now mostly a matter of how to
>> handle data migration, if we go with Kent's advice.
>>
>> Obviously no one uses NamedAssociation, since I can't see that this ever
>> worked, as there is a mismatch (serialize object and deserialize an array)
>> at the moment.
>>
>> Kent, good to know that JS is cool with that.
>>
>> The quickest fix was to change the Serializer to match the Deserializer for
>> NamedAssociations. And I am committing that version shortly in a separate
>> branch...
>>
>> But, while discussing this, I think we should do this;
>>
>> a. Change NamedAssociation to be serialized in "object" form now.
>> b. Keep the Map serialization for now as it is.
>> c. Plan the change for 3.0 later in the year, giving us a bit of time to
>> figure out the migration.
>>
>> WDYT?
> Sounds like a good plan.
>
>
Re: ZEST-23
Posted by Paul Merlin <pa...@nosphere.org>.
Niclas Hedhman a écrit :
> On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org> wrote:
>> Looking at it today I don't know why key order should matter.
>> I'd say that having more idiomatic JSON would make usage less contrived,
>> which would be a good thing.
>
> I agree that is very desirable, and it is now mostly a matter of how to
> handle data migration, if we go with Kent's advice.
>
> Obviously no one uses NamedAssociation, since I can't see that this ever
> worked, as there is a mismatch (serialize object and deserialize an array)
> at the moment.
>
> Kent, good to know that JS is cool with that.
>
> The quickest fix was to change the Serializer to match the Deserializer for
> NamedAssociations. And I am committing that version shortly in a separate
> branch...
>
> But, while discussing this, I think we should do this;
>
> a. Change NamedAssociation to be serialized in "object" form now.
> b. Keep the Map serialization for now as it is.
> c. Plan the change for 3.0 later in the year, giving us a bit of time to
> figure out the migration.
>
> WDYT?
Sounds like a good plan.
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thu, May 21, 2015 at 5:41 PM, Paul Merlin <pa...@nosphere.org> wrote:
> Looking at it today I don't know why key order should matter.
> I'd say that having more idiomatic JSON would make usage less contrived,
> which would be a good thing.
I agree that is very desirable, and it is now mostly a matter of how to
handle data migration, if we go with Kent's advice.
Obviously no one uses NamedAssociation, since I can't see that this ever
worked, as there is a mismatch (serialize object and deserialize an array)
at the moment.
Kent, good to know that JS is cool with that.
The quickest fix was to change the Serializer to match the Deserializer for
NamedAssociations. And I am committing that version shortly in a separate
branch...
But, while discussing this, I think we should do this;
a. Change NamedAssociation to be serialized in "object" form now.
b. Keep the Map serialization for now as it is.
c. Plan the change for 3.0 later in the year, giving us a bit of time to
figure out the migration.
WDYT?
Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Paul Merlin <pa...@nosphere.org>.
Paul Merlin a écrit :
> 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.
When I reworked serialization, the format was already like that (pre 2.0).
Looking at it today I don't know why key order should matter.
I'd say that having more idiomatic JSON would make usage less contrived,
which would be a good thing.
Re: ZEST-23
Posted by Paul Merlin <pa...@nosphere.org>.
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 <ni...@hedhman.org> 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
>>
>
>
>
Re: ZEST-23
Posted by Kent Sølvsten <ke...@gmail.com>.
Nope - iterating should not be a problem.
2 solutions are
for (var key in Object.keys(response)) {
alert(key + '=' + response(key);
}
or
for (var key in response) {
// excluding inherited properties
if (response.hasOwnProperty(key)) {
alert(key + '=' + response(key);
}
}
(by the way I am not a browser guy, but has done some node.js work).
Is Paul's comment about preserving order relevant for other impls than
LinkedHashMap ?
/kent
Den 21-05-2015 kl. 11:28 skrev Niclas Hedhman:
> Kent,
> good to know someone has JS experience... ;-)
>
> So, iterating response in
>
> $.getJSON( "abc.json", null, function ( response )
> {
>
> } );
>
> without knowing the structure, is not an issue?
>
>
> For data preservation, I think the existing Migration mechanism can be
> used. I need to refresh my memory...
>
> // Niclas
>
> On Thu, May 21, 2015 at 5:15 PM, Kent Sølvsten <ke...@gmail.com>
> wrote:
>
>> In javascript a map is simply a different way of accessing the r/w the
>> properties of an object.
>>
>> var map = {};
>> map["FirstName"] = ''Niclas";
>> map["LastName"] = "Hedhman";
>> var keys = Object.keys(map); // ['Firstname', 'LastName']
>>
>> ending up as
>>
>> map : {
>> "FirstName" : "Niclas",
>> "LastName" : "Hedhman"
>> }
>> when serialized as JSon.
>>
>> So i would say that the second form is definitely the "natural" one.
>>
>> Could the implementation of migrations for stored data, possibly
>> combined with specifying some sort of "protocol version" be of some use?
>>
>> /Kent
>>
>>
>>
>> Den 21-05-2015 kl. 10:37 skrev Niclas Hedhman:
>>> 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 <ni...@hedhman.org>
>> 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
>>>>
>>>
>>
>
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
Kent,
good to know someone has JS experience... ;-)
So, iterating response in
$.getJSON( "abc.json", null, function ( response )
{
} );
without knowing the structure, is not an issue?
For data preservation, I think the existing Migration mechanism can be
used. I need to refresh my memory...
// Niclas
On Thu, May 21, 2015 at 5:15 PM, Kent Sølvsten <ke...@gmail.com>
wrote:
> In javascript a map is simply a different way of accessing the r/w the
> properties of an object.
>
> var map = {};
> map["FirstName"] = ''Niclas";
> map["LastName"] = "Hedhman";
> var keys = Object.keys(map); // ['Firstname', 'LastName']
>
> ending up as
>
> map : {
> "FirstName" : "Niclas",
> "LastName" : "Hedhman"
> }
> when serialized as JSon.
>
> So i would say that the second form is definitely the "natural" one.
>
> Could the implementation of migrations for stored data, possibly
> combined with specifying some sort of "protocol version" be of some use?
>
> /Kent
>
>
>
> Den 21-05-2015 kl. 10:37 skrev Niclas Hedhman:
> > 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 <ni...@hedhman.org>
> 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
> >>
> >
> >
>
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java
Re: ZEST-23
Posted by Kent Sølvsten <ke...@gmail.com>.
In javascript a map is simply a different way of accessing the r/w the
properties of an object.
var map = {};
map["FirstName"] = ''Niclas";
map["LastName"] = "Hedhman";
var keys = Object.keys(map); // ['Firstname', 'LastName']
ending up as
map : {
"FirstName" : "Niclas",
"LastName" : "Hedhman"
}
when serialized as JSon.
So i would say that the second form is definitely the "natural" one.
Could the implementation of migrations for stored data, possibly
combined with specifying some sort of "protocol version" be of some use?
/Kent
Den 21-05-2015 kl. 10:37 skrev Niclas Hedhman:
> 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 <ni...@hedhman.org> 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
>>
>
>
Re: ZEST-23
Posted by Niclas Hedhman <ni...@hedhman.org>.
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 <ni...@hedhman.org> 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
>
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java