Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TINKERPOP-1274: GraphSON 2.0. #351

Closed
wants to merge 1 commit into from
Closed

Conversation

newkek
Copy link
Contributor

@newkek newkek commented Jun 29, 2016

https://issues.apache.org/jira/browse/TINKERPOP-1274

Summary of the changes :

Implementation of a format for value types serialization which is uniform and not Java centric. As a reminder the new format is as follows :

  • A value not typed : value
  • A value typed : [{"@type":"typeName"}, value]

The content of value can be either a simple value, or a more complex structure. The type prefix allows to call the right Deserializer to deserialize the value whatever its content is.

The default's GraphSON's 2.0 format will include types for every value that is not a JSON native type (String/int/double/null/boolean/Map/Collection) - called PARTIAL_TYPES. This allows to significantly reduce the size of the JSON payload where those types aren't needed by the Jackson library.

GraphSON serialization without types is not affected. To enable it, need to use NO_TYPES.

Quick walkthrough for the review

There are new components involved in the ser/de process that are extended from the Jackson library :

  • TypeIdResolver : performs the conversion of a object's Class -> typeID, and from a typeID -> Class.
  • TypeResolverBuilder : creates a TypeIdResolver and instantiates a TypeDeserializer or TypeSerializer with the TypeIdResolver as a param.
  • TypeSerializer : writes the prefix and suffix for a typeID. The TypeSerializer is provided to the Serializers and handles the type serialization that respects the format put in place.
  • TypeDeserializer : is called before the deserializers are called. Its role is to detect a type, and call the right Deserializer to deserialize the value.

Most of the serializers already existing for Graph had to be modified, because most of them were manually hardcoding types without calling the TypeSerializer and hence, those were not respecting the format. Now all Serializers respect the format because they call the TypeSerializer given in parameter. I followed the frame put in place by @spmallette to implement those new serializers (prefixed with V2d0) without breaking existing clients code.

In TypeDeserializer, baseType represents the class given in parameter by the user for the ser/de. If the user calls mapper.readValueAsString(jsonString, UUID.class) the baseType in TypeDeserializer will be a JavaType (which is the Jackson's custom class for Java classes) that represents a UUID class. The wildcard in our deserialization mechanism is Object.class.

The deserialization path is as follow :

  • TypeDeserializer is called only for non simple JSON values (non String/int/double/null/boolean).
  • When called, if a type is detected, the TypeDeserializer will read the typeID, convert it to a JavaType (thanks to the TypeIdResolver), check that the baseType is the same than what was read in the payload (only if baseType is not the wildcard), and call the deserialize() method of the JsonDeserializer registered for that type.
  • If a type is not detected, detect Maps or Arrays and call appropriate Deserializer.

Some results

GraphSON 2.0 shows a significant reduction of the payload's size for typed serialization. And the consequence in performance is that since there's less to process, the ser/de is faster. Results show a reduction of at least 50% in the payload's size and evolving linearly (the bigger the payload the bigger the difference) :

➜  ls -lh tinkergraph-gremlin/target/test-case-data/TinkerGraphTest/tinkerpop-io/
-rw-r--r--  1 kevingallardo  staff   890K 28 Jun 21:50 grateful-dead-V2d0-typed.json
-rw-r--r--  1 kevingallardo  staff   1.9M 28 Jun 21:50 grateful-dead-typed.json
-rw-r--r--  1 kevingallardo  staff   851K 28 Jun 21:50 grateful-dead.json
-rw-r--r--  1 kevingallardo  staff   1.5K 28 Jun 21:50 tinkerpop-classic-V2d0-typed.json
-rw-r--r--  1 kevingallardo  staff   3.6K 28 Jun 21:50 tinkerpop-classic-typed.json
-rw-r--r--  1 kevingallardo  staff   1.3K 28 Jun 21:50 tinkerpop-classic.json

Tests

Tests cover the same functionalities covered by GraphSON 1.0 typed, plus additional features brought by GraphSON 2.0.

Tradeoffs

  • Some tricks were implemented in order to provide the types without packages names. Since Java does not provide a way to search a class by its simple name, the TypeIdResolver has to have an index that it can refer to, and that has been correctly filled. The TinkerpopJackosnModule class will handle providing those new indexes to the TypeIdResolver when custom Deserializers are added, but without doing that we have no way to properly convert a type. We then require that a user instead of extending Jackson's SimpleModule when writing a module, extends TinkerpopJacksonModule which is an extension the Jackson SimpleModule. We can discuss whether this is a showstopper or if it is acceptable. Some solutions to prevent that, could be using a external library that allows searching a Class by its simple name, or switch to writing typeIDs with the full Class's canonical name. I don't have a strong opinion but it seems like the current solution is simple and good enough.
  • We loose some polymorphism potential in regards to POJOs without deserializers. Since the approach here is simpler and faster, it doesn't inspects JavaTypes to find potential subclasses. On the filp side it allows fine tuning of the Deserializers chosen to deserialize a type. I also thought about making the TypeIdResolver exposed to users through the GraphSONMapper for full customization of the types ser/de. Could be done easily later.
  • There is 1 situation that can lead to unexpected results : if somebody serializes a value that has the exact same format as the type format. I.e. a List in which the first element is a Map in which the first entry's key is GraphSONTokens.VALUETYPE. We may want to highlight that somewhere.

Extra facts

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.*;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry @newkek but your IDE introduced wildcards to our imports which isn't our code style. could you please fix those?

@spmallette
Copy link
Contributor

Note that travis isn't happy - tests are failing:

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 - 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
  • 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

@newkek
Copy link
Contributor Author

newkek commented Jun 29, 2016

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.

@spmallette
Copy link
Contributor

You might need to rebase - looks like there are conflicts on the branch - probably on CHANGELOG or something like that.

@newkek
Copy link
Contributor Author

newkek commented Jun 30, 2016

Yes the conflicts were introduced by ce19704 (reference docs and Changelog)

@newkek
Copy link
Contributor Author

newkek commented Jun 30, 2016

@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.
  • mvn clean install build's successful.

@newkek
Copy link
Contributor Author

newkek commented Jun 30, 2016

Re-conflicts with Changelog against master..

@spmallette
Copy link
Contributor

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.

@newkek newkek force-pushed the TINKERPOP-1274 branch 2 times, most recently from e15bafb to e1b6dae Compare July 1, 2016 16:40
@dmill-bz
Copy link
Contributor

dmill-bz commented Jul 1, 2016

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, the java virtual machine handles this really well, we should take advantage of it. 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.

@spmallette
Copy link
Contributor

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?

@newkek
Copy link
Contributor Author

newkek commented Jul 1, 2016

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 mean that for every typed value you would instantiate a new List<Map<>> just to read a simple value. Does that makes sense ?

@b20n
Copy link
Contributor

b20n commented Jul 1, 2016

To be very explicit, in JSON everything is Doubles and Longs

According to RFC 7159, 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?

@spmallette
Copy link
Contributor

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?

@newkek
Copy link
Contributor Author

newkek commented Jul 1, 2016

@spmallette yes, maybe some code will help explain.

        ObjectMapper mapper = GraphSONMapper.build().version(GraphSONVersion.V2_0).typeInfo(GraphSONMapper.TypeInfo.PARTIAL_TYPES).create().createMapper();
        Map<String, Integer> 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<String, Long> 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, so Double are not typed, Floats get a type.

@spmallette
Copy link
Contributor

imo, I think that if we document GraphSON this way, there should not be too much confusion as to how the type system works.

@dkuppitz
Copy link
Contributor

dkuppitz commented Jul 2, 2016

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

@robertdale
Copy link
Member

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.

@spmallette
Copy link
Contributor

  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.

  1. 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.

  1. 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.

  1. 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

@newkek
Copy link
Contributor Author

newkek commented Jul 3, 2016

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.

@spmallette
Copy link
Contributor

@robertdale
Copy link
Member

@newkek @spmallette Sorry, my context was only this thread. I agree with you on all accounts.

@newkek
Copy link
Contributor Author

newkek commented Jul 5, 2016

Just pushed the change for @class to @type. All tests pass.
'twas a 1 line fix, isn't that wonderful.

@dmill-bz
Copy link
Contributor

dmill-bz commented Jul 5, 2016

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<Map, ?> 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.

@newkek
Copy link
Contributor Author

newkek commented Jul 5, 2016

Well, I agree we cannot prevent some parsers and drivers to read the whole JSON content and check the created object for the types 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 ?

@spmallette
Copy link
Contributor

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.

@robertdale
Copy link
Member

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:

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.

[
   {
      "@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.

@newkek
Copy link
Contributor Author

newkek commented Jul 8, 2016

@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..

Also, types for serialization are known ahead of time (which may contradict what I just said), it's the Serializers that call the TypeIdResolver to put the Class in the format GraphSON accepts.

Something I'd like to mention as well is that for now, values with no Serializers aren't typed. For unknown values, the GraphSON mapper calls the toString serializer and it will "toString()" the object without writing its type. That's another tradeoff due to the fact that Java does not have a mechanism to do 'class simple name' -> Java Class. This means that serializing random POJOs will result as them being deserialized as Strings. We could work around that by saying "for random POJOs without serializers, serialize its type and the toString() value" which is possible, and during deser, if the type is not recognized Deserialize as String. Hope I was clear in the explanation. Note that GraphSON 1.0 added the type "java.lang.Object" for unknown POJOs and didn't know how to deserialize them anyway and deserialized Strings.

@spmallette
Copy link
Contributor

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:

$ 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

@spmallette
Copy link
Contributor

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.

@dmill-bz
Copy link
Contributor

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.

@okram
Copy link
Contributor

okram commented Jul 12, 2016

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<String,Class>` 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.

@spmallette
Copy link
Contributor

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.

@newkek newkek force-pushed the TINKERPOP-1274 branch 2 times, most recently from f7086f0 to 4537362 Compare August 19, 2016 14:46
@newkek
Copy link
Contributor Author

newkek commented Aug 19, 2016

Closing this in favor of #386.

@newkek newkek closed this Aug 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants