tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0
Date Fri, 01 Jul 2016 17:52:11 GMT

    [ 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:

    > 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

View raw message