[Rexster] Gremlin Extension

[stephen mallette]

I've made a number of changes to the Gremlin Extension for Rexster.  Here's a quick summary of what's new:

1. For future support of other Gremlin flavors like, gremlin-scala or gremlin-javascript, Gremlin Extension now takes a "language" parameter that allows specification of the language to execute.  By default this value is "groovy", if not specified and as there are no other flavors of Gremlin exposed in Rexster at this time, supplying any other option isn't going to get you too far.  

2. The Gremlin Script Engine now re-instantiates itself every 1000 script runs to prevent PermGen issues that have been noted.  Not a perfect fix by any means, but someone from Groovy is looking into the issue at its source: http://jira.codehaus.org/browse/GROOVY-5187 (thanks to support from James Thornton)

3. Finally, all arguments passed to the Gremlin Extension, that are not expected by the extension itself, are added to the bindings for the Script Engine which allows a request as follows:

curl -v -X POST -d '{"x":{"list":[1,2,3],"text":"test"},"script":"[x.list[0]+x.list[1]+x.list[2], x.text]"}' -H "Content-Type:application/json" http://localhost:8182/graphs/tinkergraph/tp/gremlin

which would return something like:

{

    "results": [

        6,

        "test"

    ],

    "success": true,

    "version": "0.8-SNAPSHOT",

    "queryTime": 3547.145821

}

Best regards,

Stephen

[James Thornton]

Hey Stephen -

Thanks for the updates. Why not use an explicit "params" parameter so you can eliminate the need for x.? 

Instead of...

curl -v -X POST -d '{"x":{"list":[1,2,3],"text":"test"},"script":"[x.list[0]+x.list[1]+x.list[2], x.text]"}' -H "Content-Type:application/json"http://localhost:8182/graphs/tinkergraph/tp/gremlin

It would be this... 

curl -v -X POST -d '{"params": {"list":[1,2,3],"text":"test"}, "script":"[list[0]+list[1]+list[2], text]"}' -H "Content-Type:application/json"http://localhost:8182/graphs/tinkergraph/tp/gremlin

- James

[stephen mallette]

James,

Sorry...perhaps my example or explanation of the change wasn't clear enough.  My example could have been re-written as:

curl -v -X POST -d '{"list":[1,2,3],"text":"test","script":"[list[0]+list[1]+list[2], text]"}' -H "Content-Type:application/json"http://localhost:8182/graphs/tinkergraph/tp/gremlin 

Basically, any parameter that's not expected by Gremlin Extension (script, rexster.*, language) goes into the bindings.  Hope that makes sense.

Stephen

[James Thornton]

Thanks for the clarification. However, you'll run into an issue if any of the Gremlin scripts use the "script" keyword as an argument.

- James

[stephen mallette]

I suppose I could wrap the bindings in a "bindings" argument...I'll think about that a bit.  There was a downside to doing that which I considered over the weekend when I worked on this.  I'm sorry to say I can't remember the specifics, but I think it had to do with POSTing application/x-www-form-urlencoded.  Rexster might support too many different formats to be good at all of them.  I've been quietly thinking about making it pure JSON-typing, no URL mapping to JSON and done.  

Stephen

[James Thornton]

Neo4j and OrientDB both use the "params" keyword for this...

Neo4j

http://docs.neo4j.org/chunked/snapshot/gremlin-plugin.html#rest-api-set-script-variables

OrientDB

http://code.google.com/p/orient/wiki/Gremlin#Passing_input_parameters

- James

[stephen mallette]

As I hinted in an earlier email in this thread, I'm finding Rexster is trying to do too much in some areas and, as a result, is making things more complicated than they need to be while not providing much value.  As a first step for dealing with this, I'm going to remove support for accepting application/x-www-form-urlencoded in the REST API.  I'm going to focus the REST API on JSON.

Getting back to the subject of this thread, I expect to have Gremlin Extension accepting the "params" argument when that is done. 

Best regards,

Stephen

[James Thornton]

Hi Stephen -

Moving to the JSON type system I think this is a smart move. It will definitely simplify the code, and it should be more performant. Have you figured out the best way to handle index lookups? 

Storing all index values as strings avoids the need to specify the type in the URL -- would this need to change at the Blueprints level?

Or you could accept a JSON string as a param...

http://localhost:8182/graphs/tinkergraph/indices/people?keyValue={"age":34}

http://localhost:8182/graphs/tinkergraph/indices/people?keyValue={"key":"age","value":34}

- James