Hi,
Sorry for the double-email. Let me add some more notes about Gremlin Bytecode.
Instructions that only have primitives are easy:
has name marko
Instructions that have enums require typing:
has T.label person
Instructions that have traversals require nesting:
repeat [ out knows ]
Instructions that have P predicates require typing/nesting:
has age P.gt(10).and(P.lt(32))
From here, I think we will need:
1. Enum types for Direction, Cardinality, Order, Operator, Pop, Scope, T
{@type:”Operator”, value:”sum” }
2. Traversal type for anonymous traversal nesting.
{@type:”Traversal”, bytecode: [ ] }
3. P type with nesting.
{@type: “P”, predicate: “and”, value: [ {@type: “P”, predicate:
“gt”, value: 10}, {@type: “P”, predicate: “lt”, value: 32} ]}
Thus, lets do an example:
g.V().has(“age”,gt(30)).repeat(out()).times(5).order().by(“income”,decr)
{
@type: “Traversal”,
bytecode: [
[“V”],
[“has”, “age”, { @type: “P”, predicate: “gt”, value: {@type: “int32”,
value: 30} }],
[“repeat”, {@type: “Traversal”, bytecode : [ [“out”] ] }],
[“times”, {@type: “int32”, value: 5 }],
[“order”],
[“by”, “income”, {@type: “Order”, value: “decr” }]
]
}
Something like that. Question:
Do we namespace our types?
@type: “gremlin:Traversal"
@type: “gremlin:P”
From a JSON representation like this, we can then “reply the instructions” on a
Gremlin VM to reconstruct the traversal that was generated remotely in another
language. In TINKERPOP-1278, Gremlin-Python creates a Bytecode object as the
user is doing g.V.out… then on next(), toList(), etc. that Bytecode object is
sent to a RemoteConnection (e.g. GremlinServer), the Bytecode is run on the
remote VM to create g.V.out… traversal remotely, execute it, and return results
in GraphSON.
Thats all there is to it.
Marko.
http://markorodriguez.com
> On Jul 13, 2016, at 6:53 AM, Marko Rodriguez <okramma...@gmail.com> wrote:
>
> Hello,
>
>> 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.
>
> I think we should type numbers. Already, with Gremlin-Python, I’m having
> trouble between Python’s “big integer”, Java’s long, Java’s float, Python’s
> double…. knowing the size and schema of a number is important. However, I
> believe that if something is NOT typed, then we assume it is a JSON-type.
> E.g. String, boolean.
>
>> 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.
>
> Gremlin-XXX will be sending Bytecode to Gremlin-YYY. Byte code looks like
> this:
>
> V 1
> out knows
> has name marko
> has age gt(10)
> values name
>
> Here is a thrown together JSON representation of
>
> g.V().as("a").repeat(out("created",
> "knows")).times(2).as("b").dedup().select("a", "b”)
>
> [["V"],
> ["as","a"],
> ["repeat",[["out","created","knows"]]],
> ["times",2],
> ["as","b"],
> ["dedup"],
> ["select","a","b”]]
>
> We will need a GraphSON representation of this that is Java free. This will
> be the foundational representation of serialized Gremlin traversals that can
> be passed around between Gremlin VMs and used by any programming language to
> both host Gremlin and compile traversals to this JSON-based Bytecode
> representation.
>
> Marko.
