[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 Closing this in favor of #386. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 While we have 3 +1s, I don't want to make a GraphSON 2.0 that immediately needs to be revised to a 3.0. I don't see clear consensus on what we do with types/schema and I don't think we should hold up release any further, so I think GraphSON 2.0 should be delayed for a future version when we can get everything clear. I think the core of the work done here so far however is good. I've merged this PR to here: https://github.com/apache/tinkerpop/tree/graphson-2.0 for more collaboration and discussion. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/351 Adding my email on dev@ to here. Iâm not following this PR too closely so what I might be saying is a already known/argued against/etc. 1. I think we should go with @robertdale proposal of int32, int64, Vertex, uuid, etc. instead of Java class names. 2. In Java we then have a `Map` for typecasting accordingly. 3. This would make GraphSON 2.0 perfect for Bytecode serialization in TINKERPOP-1278. 4. I think that if a Vertex, Edge, etc. doesnât have properties, outV, etc. then donât even have those fields in the representation. 5. Most of the serialization back and forth will be `ReferenceXXX` elements and thus, donât create more Maps/lists for no reason. â less chars. For me, my interests with this work is all about a language agnostic way of sending Gremlin traversal bytecode between different languages. This work is exactly what I am looking for. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/351 ok I caught up and checked code. I think what @robertdale suggests on the typing end would be really nice (`int64`, `int32`, etc). But we can keep that for the thread stephen linked to. I VOTE +1 on this. @spmallette if you could just add a mention in the documentation that the basic types are based off of the JVM types that would be a nice bonus to have. Nice work @newkek, some nice effort went into this. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 Note that I've started a new thread on the dev mailing list related to a new IO format with GLVs and Gremlin Server i mind: https://lists.apache.org/thread.html/3d7bee51fcbf63051e687a3ab82075763154902e0baf4b1c75cb672e@%3Cdev.tinkerpop.apache.org%3E If any of you have thoughts on the matter, please feel free to join the discussion there. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/351
I think we should try to merge this PR at this point (though we need one
more +1 - @PommeVerte do you have a moment to do a final review?). There are a
few little tweaks here and there, but I can quickly do those after we merge.
I configured Gremlin Server to use 2.0 and it works nicely with REST:
```text
$ curl "http://localhost:8182?gremlin=g.V(1)"
{"requestId":"7b99b15e-5d07-4cb3-b9bd-cc62d03b99ca","status":{"message":"","code":200,"attributes":{}},"result":{"data":[{"id":{"@type":"Long","@value":1},"label":"person","type":"vertex","properties":{"name":[{"id":{"@type":"Long","@value":0},"value":"marko"}],"age":[{"id":{"@type":"Long","@value":2},"value":29}]}}],"meta":{}}}
```
I expect to do more tests around the server this week.
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/351
@robertdale the format you suggest would lead to the same inconsistencies
as in GraphSON 1.0. Since the type is at the same level than the data itself,
whether the container is an Array or an Object, the type format would not be
the same. I just pushed a change in the format that is the one @PommeVerte
suggested, which gives a consistent format, without the concern of unordered
Lists (for reference the new format is `{"@type" : "typeName", "@value" :
value}`.
> please correct me if I'm wrong, but it doesn't look like the code does
any dynamic serializing.
The `TypeIdResolver` which is the object that the serializers will call to
get a TypeID from a java `Object` is dynamic in a way, in the sense that it
returns `o.getClass().getSimpleName()`. So there is no `object` -> typeID index
reference. However for the Deser, as explained in the description, Java by
default doesn't offer a way to get a Class by its simple name, so the
`TypeIdResolver` needs to keep a reference index of typeID(which is a class's
simple name) -> Java `Class`. Don't know if that answers your question..
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/351
So I've caught up on the discussion and I'll offer some more food for
thought since I haven't seen any other ideas. Embedding metadata is neither
easy nor fun (not for me anyway). For any serious integration type work it's
always best to have a well-defined schema up-front.
On types:
> @spmallette
> In fact we don't always know the types ahead of time (like Titan's
GeoPoint), so using the java class name is pretty convenient
Convenience is not the same as using Java types. By "not using java types",
we mean:
- not using java package names
- not using types specific to Java
- using primitives and other common types that are concise and portable
- should include domain-specific types. e.g. Vertex, Edge, etc.
- may include other standards. e.g. GeoJSON
Defining primitives, common types:
- http://swagger.io/specification/#dataTypeFormat
- http://bsonspec.org/spec.html
- http://geojson.org/geojson-spec.html
- http://ubjson.org/type-reference/
So if your Java implementation conveniently shares the same name as the
type, then that's wonderful. But if you are to be truly language-agnostic, then
at some point the types must be known ahead of time in order to be consumed.
For instance, how can my X parser know how to handle a Titan GeoPoint if it's
all dynamic? It can't. It must be able to handle this type ahead of time. And
I can't imagine someone would want to manually read a graphson file to discover
all the types that must be handled. Maybe I'm getting out of scope as this goes
beyond language and steps into being database agnostic. @newkek, please correct
me if I'm wrong, but it doesn't look like the code does any dynamic
serializing. It looks like all types are registered anyway. So I'll argue again
if you know your types ahead of time, then you may as well have a schema.
But let's continue with embedded metadata...
In JSON, the only unambiguous types are
- array (unless you want to disambiguate from list which may be very valid)
- string
- boolean (true, false)
- null
To avoid confusion on all other types, including numbers, they should be
typed. Thus they are objects (and not lists of things). The metadata can be at
the same level as the object and alleviates these concerns: @newkek " a List in
which the first element is a Map in which the first entry's key" and
@PommeVerte "can be a pain in systems that do not necessarily order lists".
Metadata can be differentiated from member fields by a prefix (e.g. '@').
Primitive types (or objects) having only a single value would have a "value"
key which maps to the actual value.
```json
[
{
"@type":"Vertex",
"id":{
"@type":"int64",
"value":12345
},
"label":"person",
"properties":{
"@type":"VertexProperty",
"skill":{
"id":{ "@type":"int64",
"value":8723
},
"@type":"int32",
"value":5
},
"secrets":[
{ "id":{
"@type":"int64",
"value":8723
},
"@type":"uuid",
"value":"1de7bedf-f9ba-4e94-bde9-f1be28bef239"
},
{ "id":{
"@type":"int64",
"value":8724
},
"@type":"uuid",
"value":"34523adf-f9ba-4e94-bde9-f2345bcd3f45"
}
]
},
"inE":[
{ "@type":"Edge",
"label":"knows",
"id":{
"@type":"int64",
"value":987234
},
"properties":{ },
"outV":[ { } ]
}
]
}
]
```
I wouldn't concern myself with the additional payload size for metadata. I
wouldn't sacrifice conciseness for size. One could always compress the file if
size is a concern. Also, the reader/writer could be easily enhanced to support
zip. I would take the pragmatic approach and address it when it's no longer
working for people.
Anyway, maybe this is all GraphSON 3.0 stuffs. HTH.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 This change is largely to help the consumption of GraphSON by non-JVM languages. Since I'm largely familiar with the behaviors of java based parsers and such, i'm not a good judge of that so i have to rely on @PommeVerte and others in this area. If the switch to Map is helpful then I think we should go that route. @newkek I would not be hasty in the change though. Perhaps we give it a day or so to think about to be sure that everyone is happy with that approach before you make the change and commit to it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/351
Well, I agree we cannot prevent some parsers and drivers to read the whole
JSON content and check the created object only afterward. I would not recommend
it though, because it is not great for memory consumption, but it is maybe
something we have the opportunity to avoid only thanks to Jackson and some
libraries may not offer that capability. So I guess I'll switch to the
`{"@type":"...", "value": ...}` format instead of the current one. Does that
sound good @spmallette @PommeVerte ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user PommeVerte commented on the issue: https://github.com/apache/tinkerpop/pull/351 Ok I thought The main point here was robustness in typing for non-java languages. Hence why I suggested even typing things like Int and using java classes. Honestly depending on how you compiled your PHP your basic JSON int will be converted to `Long`. And that's the case I was highlighting. It makes sense to ignore this if you're trying to reduce de payload but we'll still be lacking on the non-lossiness end. >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 You can't guaranty that the order would be maintained in some languages hence my previous comment. These languages will parse the JSON into `List` then check the list and Map along the lines of what I said in my previous post. It would be much more efficient to simply have JSON cast to `Map` and run a simple check on keys. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 Just pushed the change for `@class` to `@type`. All tests pass. 'twas a 1 line fix, isn't that wonderful. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/351 @newkek @spmallette Sorry, my context was only this thread. I agree with you on all accounts. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 Just for reference: https://groups.google.com/d/msg/gremlin-users/R7qQbJXWcH8/wK9ZuWADAwAJ --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 Yes the `@class` bothered me a little as well, since now it doesn't really describe a "Class". But I did not want to change, for consistency for GraphSON v1.0 and I reused the `GraphSONTokens.CLASS`. So if it is ok, I'd be +1 for `@type` actually. Concerning BSON (or MsgPack) it probably is indeed a more efficient serialization solution, however the goal of this PR is to optimize and improve JSON. Implementing Graph-BSON is probably another topic adjacent to this one, on which btw I'd be happy to collaborate as well. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 > 1. A type is not a class. Call types 'type' or '@type' (not clear the @ is necessary since it's in the metadata payload anyway); Not @class. (Otherwise be consistent and rename all the Type* classes to be Class*. e.g. ClassDeserializer) Changing "@class" to "@type" is ok by me if others like it. I'm not tied to one or the other - "@type" does seem a little better to me the more i think on it, but I'll let @newkek (or others) weigh in on it. > 2. Don't use Java types. Use BSON as a reference. It has a nice type system and solved most if not all of the type concerns. http://bsonspec.org/spec.html Not sure about BSON typing as a solution. Ultimately we want to know if something is a `Vertex`, `Edge`, `Duration`, `GeoPoint`, etc. In fact we don't always know the types ahead of time (like Titan's `GeoPoint`), so using the java class name is pretty convenient. 3. If space and processing efficiency is a priority, then consider actually using BSON. imo, we're pretty deep into this approach having discussed it over multiple weeks in the community. making a big switch like that is probably something to reserve for the future especially since @newkek put a fair bit of effort into this work at this point and it delivers what took a while to get agreement on. If however BSON (or some other format) could be proven a more efficient network serialization format that is truly programming language agnostic, with wide support and consistently performant parsers in the major languages we support (which is what had doomed MsgPack some time back), then I think we could consider that as an additional IO format. @robertdale if you have ideas there, it would be nice to hear them. Please consider sending a message on the dev mailing list if you do. 4. Alternatively, use an external schema to define types. It could even be appended to and a part of the output. That would be an interesting option, however would mostly be good for network serialization and not so much for file storage. So far we haven't written a network only IO package, though we have written a file storage only one with GraphML. I think that we could consider a network serialization one only since dependence on Gremlin Server for non-JVM languages is going to be something we need to support in the face of GLVs. Thanks for your thoughts @robertdale --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/351 Some suggestions: 1. A type is not a class. Call types 'type' or '@type' (not clear the @ is necessary since it's in the metadata payload anyway); Not @class. (Otherwise be consistent and rename all the Type* classes to be Class*. e.g. ClassDeserializer) 2. Don't use Java types. Use BSON as a reference. It has a nice type system and solved most if not all of the type concerns. http://bsonspec.org/spec.html 3. If space and processing efficiency is a priority, then consider actually using BSON. 4. Alternatively, use an external schema to define types. It could even be appended to and a part of the output. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/351 I hope you guys figured it all out yesterday.I didn't follow all the comments, but started a `docker/build.sh -t -i -n` over-night job. It succeeded, thus VOTE: +1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 imo, I think that if we document GraphSON this way, there should not be too much confusion as to how the type system works. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue:
https://github.com/apache/tinkerpop/pull/351
@spmallette yes, maybe some code will help explain.
```
ObjectMapper mapper =
GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create().createMapper();
Map map = new HashMap<>();
map.put("helo", 2);
String s = mapper.writeValueAsString(map);
// prints 's = {"helo":2}'
System.out.println("s = " + s);
Map read = mapper.readValue(s, Map.class);
// prints 'read.get("helo") = class java.lang.Integer'
System.out.println("read.get(\"helo\") = " +
read.get("helo").getClass());
Map map3 = new HashMap<>();
map3.put("helo", 2L);
String s2 = mapper.writeValueAsString(map3);
// prints 's2 = {"helo":[{"@class":"Long"},2]}'
System.out.println("s2 = " + s2);
Map read2 = mapper.readValue(s2, Map.class);
// prints 'read2.get("helo") = class java.lang.Long'
System.out.println("read2.get(\"helo\") = " +
read2.get("helo").getClass());
```
> number with decimal and no type = Java Float
Almost, by default decimals are Double, not Floats.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 If i understand right: Serializing integer without a type tag would result in integer. You would have to specify "Long" as the type for it to be interpreted as a Long in java. This is generally just a problem for numerics so the conversion is: * number with no decimal and no type = Java integer * number with decimal and no type = Java Float * all other numerics will have a java type present (simple name) @newkek is that an appropriate description of what's happening in conversion? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user banjiewen commented on the issue: https://github.com/apache/tinkerpop/pull/351 > To be very explicit, in JSON everything is Doubles and Longs According to [RFC 7159][1], all numerics (i.e., both integral and decimal) in JSON are of a single type, Numeric, with implementation-specific ranges. In any case would "assuming Integer" result in payloads that don't round-trip to the same types? For example, if I serialize an Integer without a type tag, will subsequent deserializations (via, say, Jackson) return a Long? [1]: https://tools.ietf.org/html/rfc7159#section-6 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
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 t
yped, 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>` 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>` just to read a simple value. Does that makes
sense ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/351
I thought that java integer would be implied. I believe that if we wrote a
java short for example it would type to a "Short" then you would know what kind
of number it is.
We purposely went away from the fully qualified class name which really
doesn't mean much to non-JVM languages in favor of the more brief and less
scary simple name - I thought we had decided that a smaller byte size for the
network outweighed the downside of being less specific about the type. no?
> I would also like to point out that this format
[{"@class":"java.lang.Integer"}, 1] can be a pain in systems that do not
necessarily order lists.
I seem to remember that we discussed that before but don't remember the
outcome - @newkek do you remember what was said?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user PommeVerte commented on the issue:
https://github.com/apache/tinkerpop/pull/351
Hey guys,
I've been super busy lately but I definitely plan on diving deep into this
PR over the weekend. One quick remark though.
1. Even the JSON supported types are not prone to lossiness in multi
language settings. They should also be typed.
2. In a multi language setting, having type names without their java
classes is not helpful.
I can illustrate both of these points with the following JSON : `{"id":1}`
The client assumes `id` is `int` but what exactly is an int? is it `16bit`,
`32bit`, or `64bit`? Languages will have their own definition here. Actually
some languages will even have different values of `int` depending on how they
were compiled.
Changing it to `{"id":[{"@class":"Integer"}, 1]}` is not helpful in this
case either. However the following is explicit and is something you can work
with: `{"id":[{"@class":"java.lang.Integer"}, 1]}`. It's immediately
identifiable and well documented. The client knows this is a 32bit Int and can
work accordingly. Without this you would have to go through documentation or
code to figure out what you were dealing with.
In conclusion:
1. Thinking about it some more it's possible that Integer is the only
special case that would need typing in the json supported types. I'll give it
some more though. We could possibly have a "verbose" option for those who
require typing of everything.
2. Type names should refer to the java class. This also seems to make sense
when dealing with custom objects.
PS: I would also like to point out that this format
`[{"@class":"java.lang.Integer"}, 1]` can be a pain in systems that do not
necessarily order lists. With these systems you need to check that your list
has two elements, that one is a map, and that the map contains a `@class` key.
Costly operation.
Perhaps `{"@class":"java.lang.Integer", "value": 1}` is a better option.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 yeah - we tend to bump heads on master a little bit on the CHANGELOG - not a big deal - i can resolve that conflict when the time comes. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 Re-conflicts with Changelog against master.. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 @spmallette - I've written all the docs, please don't hesitate to correct them if they're not written well. - Updated the tests, parameterized them as much as possible, and focused the 2.0 tests on the 2.0 specific functionalities. - Rebased on current `master`. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 Yes that was introduced by the ce19704 (reference docs and Changelog) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user newkek commented on the issue: https://github.com/apache/tinkerpop/pull/351 > tests are failing Ah I changed something quickly this morning and did not run again those tests. Will correct that. Ok for the docs, will do. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/351 Note that travis isn't happy - tests are failing: ```text Failed tests: GraphSONMessageSerializerV2d0Test.shouldSerializeToJsonIteratorNullElement:147 expected:<[x]> but was:<[]> GraphSONMessageSerializerV2d0Test.shouldSerializeToJsonMap:171 expected:<[x]> but was:<[]> GraphSONMessageSerializerV2d0Test.shouldSerializeToJsonIterable:107 expected:<[x]> but was:<[]> GraphSONMessageSerializerV2d0Test.shouldSerializeToJsonIterator:126 expected:<[x]> but was:<[]> ``` Also - some documentation odds and ends: * Please update CHANGELOG with an entry for "Introduced GraphSON 2.0". * We probably need o include some reference documentation [here](https://github.com/apache/tinkerpop/blob/5395aaeb057e4c163233aa8ace2a2975ea827fe5/docs/src/reference/the-graph.asciidoc#graphson-readerwriter) - not sure what that should look like at the moment. We default to 1.0 still for now, so we probably don't need to change too much. Perhaps we need a section that shows what 2.0 format looks like and how to generate it? Maybe that is enough? * We need upgrade docs for users so they are aware of this new feature - [here](https://github.com/apache/tinkerpop/blob/5395aaeb057e4c163233aa8ace2a2975ea827fe5/docs/src/upgrade/release-3.2.x-incubating.asciidoc#upgrading-for-users) * We need upgrade docs for driver devs (need to add a section - no changes in 3.2.1 have affected drivers yet) so they are aware of how they might benefit from this change - [here](https://github.com/apache/tinkerpop/blob/5395aaeb057e4c163233aa8ace2a2975ea827fe5/docs/src/upgrade/release-3.2.x-incubating.asciidoc#upgrading-for-providers) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
