Re: withBindings() -- the final piece of the TINKERPOP-1278 puzzle.

Since RemoteGraph is used on the client to connect to a remote graph database, I think its fine to have a tight coupling between the binding and the traversal source, since that allows for binding reuse when multiple queries are issued in one session. As such, one would instantiate a traversal

withBindings() -- the final piece of the TINKERPOP-1278 puzzle.

Hello, ScriptEngine’s prefer to have compile scripts with bindings as a compiled script will execute much faster than one that needs to be compiled. Thus, for a traversal that will be run over and over again, but with for instance different g.V(id) sources, its all about using ScriptEngine

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, In TINKERPOP-1278, I registered GraphSON Serializers and Deserializers for Bytecode, P, and Enums.

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

i'll answer your second email first about GraphSON because it's shorter and i know the answer without too much thought (i'll need to take some time to think on the other). So the answer to "is this true?" is yes and no. The "yes" part is related to the fact that I believe that by default

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

> First, is there a wiki that we can keep updated with decisions or at least decision points? I know there's an old wiki, but is there/will there be a new wiki? No - we don't have a wiki. Design decisions tend to get trapped in the mailing list (or JIRA) which isn't so good. Maybe that's a

[jira] [Commented] (TINKERPOP-1278) Implement Gremlin-Python and general purpose language variant test infrastructure

[ https://issues.apache.org/jira/browse/TINKERPOP-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15375441#comment-15375441 ] ASF GitHub Bot commented on TINKERPOP-1278: --- Github user asfgit closed the pull request at:

[GitHub] tinkerpop pull request #359: TINKERPOP-1278 : Removed long literal 'L' suffi...

Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/359 --- 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

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

First, is there a wiki that we can keep updated with decisions or at least decision points? I know there's an old wiki, but is there/will there be a new wiki? Stephen, IMO, that's still bad behavior. That says to me a number is not a number. But, yes, schemaless does allow one to put crap in and

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

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 The

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

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')

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

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

[jira] [Created] (TINKERPOP-1373) Default gremlinPool to number of cores

stephen mallette created TINKERPOP-1373: --- Summary: Default gremlinPool to number of cores Key: TINKERPOP-1373 URL: https://issues.apache.org/jira/browse/TINKERPOP-1373 Project: TinkerPop

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

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