The transaction array is a closure within the module

[richtera]

The transaction array is a closure within the module

[fattenap]

Hi richtera,

I've updated gRex to cater for multiple connections. It meant I had to change the API a little with regards to Transactions and how they are handled. If you would like to try it out it is in the 0.2.0 branch. The Readme in that branch reflects the changes. But here are the highlights.

To start a transaction you need to call begin. Below is an example of how to do it.

var trxn = g.begin();
var v1 = trxn.addVertex({'test':'NameA'});
var v2 = trxn.addVertex({'test':'NameB'});
trxn.addEdge(v1, v2, 'aLabel');
trxn.commit().then(function(result){
console.log(result);
}, function(err) {
console.error(err)
});

Some other things to note.

Transaction success no longer requires testing for success = true || false. Only successful values are returned to success callback. All errors are sent to error callbacks.

I totally removed get() from the API, as it was a redundant call.

I haven't pushed this branch to NPM as yet. I has some minor adjustments to make before doing that. But if you have the time it would be great if you could give this a try.

Thanks
Frank

[richtera]

Much better, although I would really like even require('grex') to return a constructor accepting options so I can have multiple connections. I also noticed that when executing g.V('key', val) where val is a variable only works for numbers or expressions matching graph references or ids. I have val being a plain string and wrapping it with quote also does the wrong thing. I can work on a pull request for that if you'd like.
I was thinking of changing _parseArgs to look for single or double quote in the beginning of strings passed in and then output them into gremlin verbatim.

[fattenap]

Great. So you confirm that the Transactions work as you expect. With regard to the other issues.

I think the constructor approach is a good idea. I'll look at that for a future release.
The g.V('key', val) looks like a bug. Are you able to open another issue with this scenario. Maybe give an example of what you are trying to do.

And all pull requests are welcome and appreciated, so feel free to submit a pull request.

Thanks
Frank

[richtera]

Yes transactions work well although tp:batch doesn't use json types whereas addVertix does. So adding a vertex using addVertex and then updating using updateVertex will modify all data to string format.
I temporarily added support to pass {verbatim:json} as any parameter. This allows you to use JSON.stringify() when you know the parameter is of a specific type.
I was thinking of adding typed stuff using "(list,(...))" "(map,(id=..." and so on as part of parameter parsing.
Thanks
Andy

On Jul 16, 2013, at 9:10 PM, Frank Panetta [email protected] wrote:

Great. So you confirm that the Transactions work as you expect. With regard to the other issues.

I think the constructor approach is a good idea. I'll look at that for a future release.
The g.V('key', val) looks like a bug. Are you able to open another issue with this scenario. Maybe give an example of what you are trying to do.

And all pull requests are welcome and appreciated, so feel free to submit a pull request.

Thanks
Frank

—
Reply to this email directly or view it on GitHub.

[fattenap]

OK Thanks. I'll close this off and publish to NPM the first chance I get.

Also I thought tp:batch did use json types. I should check out what's going on there.

The typing would be a good addition, but I would like to keep the syntax as close to gremlin as possible. We may need to flesh this out.

Thanks
Frank