This issue all seems to trap users (even pre-TP3): gremlin> graph = TinkerGraph.open() ==>tinkergraph[vertices:0 edges:0] gremlin> g = graph.traversal() ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard] gremlin> g.addV(id,1l) ==>v[1] gremlin> g.V(1) gremlin> g.V(1L) ==>v[1]
We see it again here on the gremlin-users mailing list today: https://groups.google.com/d/msg/gremlin-users/Nb7v1-ihFgY/nG73rO-WrHcJ and its impact on non-JVM languages using GraphSON serialization with Gremlin Server. Here's a few thoughts for how we might try to make this better: 1. Take care of it at the Graph level. In the test suite, force graphs that supportsNumericIds to properly resolve any Number (long, int, etc) given as an Id (the most common case for getting this wrong). Force those that supportsCustomIds to accept a "string" representation of that id. In this way, Graph identifiers can fit in basic JSON types. 2. Make it so that Gremlin Server coerces JSON types to some standard form. Rexster sorta worked this way with RexPro where there was lossiness with MsgPack. Maybe Gremlin Server has some configuration for this? Not a perfect solution being so high in the stack and certainly doesn't fix the console example above. 3. Introduce a more simplistic type system to Gremlin Server's GraphSON....something less verbose than what you get with the embedTypes setting on the GraphSONWriter?? Rexster had a system for doing this, but it didn't feel like a great approach. Again, this doesn't really fix problems with the Console example. Not sure it helps Dylan either given what was stated in that post above. I don't know if option 1 is the right answer, but I like the idea of solving this at the Graph level somehow so that the benefit goes up the stack any other ways to do it? how about reasons for not trying to settle it at the gremlin-core/Graph level? Thanks, Stephen
