Anyone using Tinkerpop docker as a local Cosmos replacement
Running into some random issues. Looking for tips and tricks.
Solution:Jump to solution
One thing to consider in trying to do this is that you would likely use TinkerGraph and Gremlin Server for this local replacement. CosmosDB has a number of limitations and differences that this local environment would not catch, so it's possible that you could write some Gremlin that works locally but then fails when you try the same query on CosmosDB. That said, if you stay aware of those differences, stick to sending scripts and prefer the 3.4.x server release it could give you a basic but not...
4 Replies
Solution
One thing to consider in trying to do this is that you would likely use TinkerGraph and Gremlin Server for this local replacement. CosmosDB has a number of limitations and differences that this local environment would not catch, so it's possible that you could write some Gremlin that works locally but then fails when you try the same query on CosmosDB. That said, if you stay aware of those differences, stick to sending scripts and prefer the 3.4.x server release it could give you a basic but not perfect replacement.
So ran into one quirk, curious if there's a work around. On Cosmos, if you order().by on a non-existing field, you get all the items in a random order. On Tinkerpop, you don't get any items. The order().by acts as a "where" which is unexpected.
Usage of
by() was incredibly inconsistent prior to 3.6.0. It behaved a lot of different ways for different steps that surprised people. At 3.6.0 the behavior settled on:
If the by() produces a result then it is said to be "productive" and its value is propagated to the step for use. If the by() does not produce a result then the traverser to which it was to be applied is filtered.At the time, we offered
g.withStrategies(ProductiveByStrategy) to force by() to be productive even when it wasn't, but that wouldn't be available to CosmosDB which to the best of my knowledge is still on 3.4.x behavior. Since it's on some form of 3.4.x, i'm not even sure null production for failed by() modulators was available. You might try something like:
you can read more here if interested: https://tinkerpop.apache.org/docs/current/upgrade/#_consistent_by_behaviorThanks, it turns out the easiest answer for us is to just shove a default value on those objects, but I was surprised by that behavior.