Azure-docs: Gremlin.NET - is this a good recommendation?

[JamesRandall]

Left this over on Twitter too (@azuretrenches) - is the TinkerPop Gremlin.NET package a good recommendation at the moment? I'm not sure it is against Cosmos DB. It doesn't expose errors such as rate limiting in a way that allows resilience policies (such as from Polly) to be elegantly used as it swallows the error codes and only returns strings - that then require string parsing to determine the meaning (in this specific case the 429 is returned in an MS header while the HTTP status code is 500 but Gremlin.NET has no awareness of this, RequestRateTooLargeException is returned in the exception message text). Not great for busy distributed systems.

I have started work on a PR that would allow for vendor extensions to be exposed (as it's also incredibly useful to be able to see RU usage etc.) but at the moment, unless I'm missing something, not convinced this is a great choice of package to be driving people towards against Cosmos.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 2700fc00-4872-6fcf-65e0-ab9fd5fde2a1
• Version Independent ID: e828bbb5-2c22-17f2-32aa-aa3773c55806
• Content: Build an Azure Cosmos DB .NET Framework or Core application using the Graph API
• Content Source: articles/cosmos-db/create-graph-dotnet.md
• Service: cosmos-db
• GitHub Login: @LuisBosquez
• Microsoft Alias: lbosq

[mimckitt]

@JamesRandall Thanks for the feedback! We are currently investigating and will update you shortly.

[Mike-Ubezzi-MSFT]

@JamesRandall Yes, Azure Cosmos DB supports Apache Tinkerpop's graph traversal language, Gremlin, which is a Graph API for creating graph entities, and performing graph query operations. You can use the Gremlin language to create graph entities (vertices and edges), modify properties within those entities, perform queries and traversals, and delete entities. Read more...

You are correct in your assessment about RequestRateTooLarge and Cosmos DB. You can read more here.
The only thing I have to add is that the .NET Client SDK and LINQ queries handles this exception automagically:

---

If you are using the .NET Client SDK and LINQ queries, then most of the time you never have to deal with this exception, as the current version of the .NET Client SDK implicitly catches this response, respects the server-specified retry-after header, and retries the request. Unless your account is being accessed concurrently by multiple clients, the next retry will succeed.

---

I hope this information helps. Please let me know if you still have an outstanding question or need additional information.

[JamesRandall]

Thanks for looking into it. I'm aware of the .NET Client SDK - I've used it on previous projects but gave the Tinkerpop variant ago after refreshing myself with the docs yesterday.

My point is should a quickstart tutorial be sending people down what is essentially a blind alley for .NET developers on anything except "toy" type development? Particularly when people are learning Cosmos if they pickup this package they're going to find themselves getting errors that are unobvious how to parse and handle.

I'd suggest the focus should be on the .NET Client package with the Tinkerpop package presented elsewhere as an alternative.

[mimig1]

Pinging @LuisBosquez via email.

[LuisBosquez]

Hello @JamesRandall, we're actively working on improving the Gremlin.Net package along with the community. One of the immediate items we're working on is exposing the CosmosDB specific metadata for each request. We want to not depend on our specific libraries and enhance the support for the open source connectors in the future.

[JamesRandall]

Thanks @LuisBosquez - it seems a bit like being stuck between a rock and a hard place as a .NET developer with Cosmos and Graph at the moment. The old clients being deprecated and the alternative not really supporting real world scenarios.

Do you have any timescales for when Gremlin.NET will support at a minimum better error handling?

I'd gathered you were heading towards the open source libraries and so if it helps I've worked around this for the moment by forking the Gremlin.NET library, from the Tinkerpop repo, and making a set of API compatible changes that expose vendor attributes and status codes.

I'd go a little further to make it friendlier to use (pluggable vendor extensions might be nice) but it works for now and is compatible with the published package.

I need to go through the code again as I did this in a hurry to get out of a jam but was considering submitting a pull request if thats helpful. Code is here:

https://github.com/JamesRandall/tinkerpop/tree/master/gremlin-dotnet

[LuisBosquez]

Thanks @JamesRandall!

At the moment we are having a discussion with the open-source community of Apache Tinkerpop with a design to expose server messages and status codes. It's not a matter of writing the code, as much as it is to make sure that the community agrees upon a design that is extensible and generalizable. You can see the current discussion here: https://issues.apache.org/jira/browse/TINKERPOP-1913 Also, due to the fact that this also depends on the community's approval, there isn't a timeline I can share right now.

There's another fork of Gremlin.Net that incorporated a few other issues, including an approach for GLV (typesafe Gremlin in a Fluent API manner) as well as deserialization using custom objects: https://github.com/evo-terren/Gremlin.Net.CosmosDb It's worth a look, and maybe this would be a good place to include a PR on your server messages contribution. What do you think?

[LuisBosquez]

please-close

[JamesRandall]

Thanks @LuisBosquez - I'll take a look at that fork, cheers!

[awwillis]

The Gremlin.NET library now supports this (as of 3.4.0-rc2).

SubmitAsync<T> now returns either a ResultSet that contains a StatusAttributes collection on success or throws a ResponseException with a StatusAttributes collection in the case of a failed query.

The status attributes include all the cosmos-db specific attributes such as the cost of the query in RUs, the request status code, and the 'back-off' time to wait.

[JamesRandall]

Great! Thanks for the update. I'm currently doing quite a lot of work with Gremlin against Cosmos so will give that a go.

[jackbond]

When it comes to .NET and Gremlin support, the support is still a complete joke. Just look at the sample on this page...

string output = JsonConvert.SerializeObject(result);

Seriously? The client library has just deserialized the json off the wire, and what is the author doing here? Re-serializing it? But I get why this did the lazy cheat, what happens if you try and actually parse the dynamic object you've been given back? Well eventually to get the vertex properties you're interested in, you'll find they've been tucked away into a ...

System.Linq.Enumerable+SelectIListIterator

Awesome, an internal class you've got to search github to find the source if you want to move forward.

So thinking I'd tried something different, I tinkered around with something like this...

Graph graph = new Graph();

var traversalSource = AnonymousTraversalSource.Traversal().WithRemote(remoteConnection);

var vertex = traversalSource.V(useridentifier);//.InE("primaryEmail").OutV();

All I could get was null reference exceptions.

So once again, Cosmos is a great database engine. Unfortunately, the people writing the SDKs and documentation are so grotesquely incompetent that it boggles the mind. You can search for HOURS and make absolutely ZERO progress on how to effectively use Cosmos.