Hi,
Here is a toy class I just made that converts Bytecode to “GraphSON2.0.” I
believe it covers everything! (save I didn’t blow out the Number section):
https://gist.github.com/okram/908b73b24e8db48f1006124942a900b1
<https://gist.github.com/okram/908b73b24e8db48f1006124942a900b1>
The following code:
Traversal<?, ?> traversal =
__.V().has("age",
gt(10).and(lt(30))).out("knows").repeat(out().hasLabel("person")).times(2).groupCount().by(label);
GraphSONWriter.build().create().writeObject(System.out,
GraphSONConverter.convert(traversal));
Outputs:
{"bytecode":[["V"],["has","age",{"predicate":"and","@type":"P","value":[{"predicate":"gt","@type":"P","value":{"@type":"int32","value":10}},{"predicate":"lt","@type":"P","value":{"@type":"int32","value":30}}]}],["out","knows"],["repeat",{"bytecode":[["out"],["has","~label",{"predicate":"eq","@type":"P","value":"person"}]],"@type":"Traversal"}],["times",{"@type":"int32","value":2}],["groupCount"],["by",{"@type":"T","value":"label"}]],"@type":"Traversal"}
Or in pretty print:
{
"bytecode": [
[
"V"
],
[
"has",
"age",
{
"predicate": "and",
"@type": "P",
"value": [
{
"predicate": "gt",
"@type": "P",
"value": {
"@type": "int32",
"value": 10
}
},
{
"predicate": "lt",
"@type": "P",
"value": {
"@type": "int32",
"value": 30
}
}
]
}
],
[
"out",
"knows"
],
[
"repeat",
{
"bytecode": [
[
"out"
],
[
"has",
"~label",
{
"predicate": "eq",
"@type": "P",
"value": "person"
}
]
],
"@type": "Traversal"
}
],
[
"times",
{
"@type": "int32",
"value": 2
}
],
[
"groupCount"
],
[
"by",
{
"@type": "T",
"value": "label"
}
]
],
"@type": "Traversal"
}
Thoughts?,
Marko.
http://markorodriguez.com
> On Jul 13, 2016, at 9:30 AM, Stephen Mallette <spmalle...@gmail.com> wrote:
>
> Marko, the namespacing idea seems smart.
>
> Robert, I think other graphs have similar behavior to TinkerGraph's
> default. In Titan, the absence of a schema (default, obviously) produces
> this:
>
> gremlin> graph = TitanFactory.open('conf/titan-cassandra-es.properties')
> ==>standardtitangraph[cassandrathrift:[127.0.0.1]]
> gremlin> graph.addVertex("n",100D)
> ==>v[4288]
> gremlin> graph.traversal().V().has('n',100f)
> gremlin> graph.traversal().V().has('n',100d)
> ==>v[4288]
>
> This kind of problem has caused trouble for years and years in TinkerPop
> and allowing the type to be embedded seemed like a good solution. Of
> course, you bring up a good point about javascript - to this point we've
> relied on JS devs to conform to java/groovy types by forcing conversion in
> their gremlin scripts or configuring their graphs to avoid use of types
> that would produce these kinds of ambiguous results.
>
>
>
> On Wed, Jul 13, 2016 at 9:51 AM, Robert Dale <robd...@gmail.com> wrote:
>
>> And just to be clear, I'm not necessarily disagreeing. But I think
>> it's important to understand where and why it's necessary.
>>
>> For example, if I'm writing a gremlin script (string), I don't type my
>> input numbers. It's rightly converted by the underlying architecture.
>> (I'm guessing groovy which has enhanced number support). Also, if a
>> GLV is submitting typed numbers, how would that work? For example, in
>> Javascript?
>>
>> On Wed, Jul 13, 2016 at 9:16 AM, Robert Dale <robd...@gmail.com> wrote:
>>> Hi, Stephen. I think that's a bad example. You may recall I brought
>>> up that issue in the forum. However, it's actually attributed to the
>>> default ID manager of ANY (for historical) which I think is a really
>>> bad default (and reason) because it only leads to confusion. Java is
>>> one of the few, if not only, brain-damaged languages where 5 != 5 !=
>>> 5. In Java, number objects must be coerced into like form for
>>> comparison. The other ID managers do this coercion. Saner languages
>>> do this under the covers.
>>>
>>> On Wed, Jul 13, 2016 at 8:56 AM, Stephen Mallette <spmalle...@gmail.com>
>> wrote:
>>>> Robert, thanks for joining this discussion.
>>>>
>>>>> I wonder if it even makes sense to type numbers according to their
>>>> memory model. As objects, Byte, Short, and Integer occupy the same
>>>> space. Long isn't much more. So in Java we're not saving much space.
>>>> Jackson will attempt to parse in order: int, long, BigInt, BigDecimal.
>>>> The JSON JSR uses only BigDecimal. Some non-jvm languages don't even
>>>> have this concept. Does anything in gremlin actually require this?
>>>>
>>>> If the intended numeric type isn't preserved, weird things can happen
>> with
>>>> graphs that have a schema (like Titan/DSE). Even TinkerGraph using the
>>>> default ID manager will not be happy if you try to do a lookup of Long
>>>> identifiers with an Integer:
>>>>
>>>> gremlin> graph = TinkerFactory.createModern()
>>>> ==>tinkergraph[vertices:6 edges:6]
>>>> gremlin> graph.vertices(1)
>>>> ==>v[1]
>>>> gremlin> graph.vertices(1L)
>>>> gremlin>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 13, 2016 at 8:17 AM, Robert Dale <robd...@gmail.com> wrote:
>>>>
>>>>> Marko, I agree that empty object properties should not be represented.
>>>>> I think if you saw that in an example then it was probably for
>>>>> demonstration purposes.
>>>>>
>>>>> Kevin, can you expand on this comment:
>>>>>
>>>>>> 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
>>>>>> https://github.com/apache/tinkerpop/pull/351#issuecomment-231351653
>>>>>
>>>>> What exactly are the inconsistencies? What is the problem in
>>>>> determining an array or object?
>>>>> This is a natural JSON array (or list): []
>>>>> This is a natural JSON object: {}
>>>>>
>>>>> Type at the object level is a common pattern and supported feature of
>>>>> Jackson. Also, GeoJSON would be a natural fit as it also stores
>>>>> 'type' at the object level. Titan supports GeoJSON currently. I
>>>>> wonder if it would make sense to promote geometry to gremlin.
>>>>>
>>>>> We should probably start documenting a table of supported types. (If
>>>>> there is one, please provide link)
>>>>>
>>>>> I wonder if it even makes sense to type numbers according to their
>>>>> memory model. As objects, Byte, Short, and Integer occupy the same
>>>>> space. Long isn't much more. So in Java we're not saving much space.
>>>>> Jackson will attempt to parse in order: int, long, BigInt, BigDecimal.
>>>>> The JSON JSR uses only BigDecimal. Some non-jvm languages don't even
>>>>> have this concept. Does anything in gremlin actually require this?
>>>>> I'm thinking that this is only going to be relevant at the domain
>>>>> model level. This way json native numbers can be used and not need
>>>>> typing.
>>>>>
>>>>> Additionally, I think that all things that will be typed should always
>>>>> be typed. For the use cases of injesting a saved graph from a file, it
>>>>> can probably be assumed that the top-level objects are vertices since
>>>>> the graph is vertex-centric and everything else follows naturally.
>>>>> I'm not entirely sure what is required for submitting traversals to
>>>>> gremlin server from GLV. However, if this is used for the results
>>>>> from gremlin server then the results could start with any one of path,
>>>>> vertex, edge, property, vertex property, etc. So you'll need that type
>>>>> data there.
>>>>>
>>>>> --
>>>>> Robert Dale
>>>>>
>>>>> On Tue, Jul 12, 2016 at 8:35 AM, Marko Rodriguez <okramma...@gmail.com
>>>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> 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 Robert Dale’s 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.
>>>>>>
>>>>>> Thanks,
>>>>>> Marko.
>>>>>>
>>>>>> http://markorodriguez.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jul 9, 2016, at 9:48 AM, Stephen Mallette <spmalle...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> With all the work on GLVs and the recent work on GraphSON 2.0, I
>> think
>>>>> it's
>>>>>>> important that we have a solid, efficient, programming language
>> neutral,
>>>>>>> lossless serialization format. Right now that format is GraphSON
>> and it
>>>>>>> works for that purpose (ever more so with 2.0). Given some
>> discussion
>>>>> on
>>>>>>> the GraphSON 2.0 PR driven a bit by Robert Dale:
>>>>>>>
>>>>>>> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
>>>>>>>
>>>>>>> I wonder if we shouldn't consider another IO format that has Gremlin
>>>>>>> Server/GLVs in mind. At this point I'm not suggesting anything
>> specific
>>>>> -
>>>>>>> I'm just hanging the idea out for further discussion and brain
>> storming.
>>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Robert Dale
>>>>>
>>>
>>>
>>>
>>> --
>>> Robert Dale
>>
>>
>>
>> --
>> Robert Dale
>>
