[
https://issues.apache.org/jira/browse/TINKERPOP-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359364#comment-15359364
]
ASF GitHub Bot commented on TINKERPOP-1274:
-------------------------------------------
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/351
> I thought that java integer would be implied.
Yes with the current PR serializing an Integer will result in no type
added. Serializing a Long or a Short will result in an explicit type added. To
be very explicit, in JSON everything is Doubles and Longs, it does that because
it's the bigger container format that contains the others less precise ones.
Jackson however, considers that when an Integer is to be serialized, there is
no need for an explicit type because the precision will be kept since for JSON
it's in a Long. When it comes to serializing a Long, still no precision loss
but the format explicitly indicates to the Deserializer that what has been
serialized initially was a Long. So everything is as defined as if the Integer
was typed, because by default the reader assumes everything's an Integer, and
if not there will be a type to specify what it is. However we have save a large
payload size by not typing the integer. Same concept for Float VS Double, for
JSON everything is a Double, if a value is a Float, it will be typed, if not,
by default it's a Float.
So as I said in the description I think the outcome of the mail
conversation was to not type Simple values. Mostly because we're not sure if
this is going to be useful or not. However, adding those types in the future,
for Simple values, can be very easily done and I've left detailed comments in
the `TypeSerializer` on how to add them when we deem it necessary. Also, adding
them would not break existing code since the format would be the same, it's
just that _every_ value would follow the format for typed values. Since there's
no possibility to mix-up for the Numeric values as explained above with the
Shorts and Longs and etc... I still think we should wait somebody explicitly
requires it.
> Perhaps {"@class":"java.lang.Integer", "value": 1} is a better option.
As I see it for how I implemented the TypeDeserializer, it acts as a meta
deserializer that will read the raw text JSON sequentially, so there's no
chance there can be a mixup in the order, it does not deserialize the whole
structure and creates a `List<Map<>>` object. Same for the TypeSerializer, it
does not create a Java `List` object to write the type, but it writes directly
in JSON "write a start_array token, write a start_map token, write a property
name, write a text field (the type name), write a end_array token, etc" so same
thing, there is no chance there can be a mix up in the order.
I don't know what it could look like for parsers of other languages, but it
would seem like doing something else than that would be quite inefficient in
terms of performance because it would that for every typed value you would
instantiate a `new List<Map<>>` just to read a simple value. Does that makes
sense ?
> GraphSON Version 2.0
> --------------------
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
> Affects Versions: 3.1.2-incubating
> Reporter: stephen mallette
> Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for
> non-JVM languages that consume it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
