Does the TinkerGraph in-memory database support List cardinality properties for vertices?
elementMap()
assumes that cardinality for each key is single and if it is list then only the first item encountered will be returned.
To get all property values valueMap()
step can be used instead.
`gremlin> g.V(1).property("address", "a1").property(list, "address", "a2")
==>v[1]
gremlin> g.V(1).valueMap()...Analyzing samples of Gremlin Queries in Neptune Notebook
.in
or .out
steps without clarifying the entity name, it's almost impossible to analyze which part of ontology was visited. We also want to identify common query patterns to understand what people are usually querying for and which connections in our ontology are the most frequently used, but also filtering out some common to all queries parts, like g.V()
or g.V()
, retrieving rather information about combinations of multiple steps that were called.
We’ve figured out how to override the Gremlin magic in Neptune Notebook to add our custom logic to handle each query. And for my problem I’m considering two approaches:...profile.indexOps
to True
and you'll get an output at the bottom of the profile output with every index operation that occurs. These will equate to some permutation of S-P-O-G patterns that are used in the three different built-in indexes (or fourth index, if enabled).With the list of indexed lookup patterns, you could possibly maintain an external counter (maybe in sorted set in Redis/Valkey) with a a key of the S-P-O-G combination and the value being the number of times accessed. Just be aware that attaining a Neptune Gremlin Profile output requires that you run the query again. So you may not be able to use this to capture writes (without rewriting the data) and it will incur additional database resources to re-run all of the read queries....
Potential bug in evaluationTimeout when using auth?

Should `barrier` step merge Edge properties with the same key and value?
barrier
to merge multiple traversers of different Edge properties together (a.k.a. optimization). Currently, as the result of such merging some Edge properties might be missing from the continuing traversal. For example, the following test will fail as the last line because a single property is still left after all "name" properties removal (graph.traversal().E().properties("name").barrier(5).drop().iterate()
). I.e. I had impression that barrier
step may influence query optimization, but not influence query result. Now I'm trying to understand if that is the intended behavior or not.
```
@Test
public void testDropsEdgePropertiesTinkerGraph() {
Graph graph = TinkerGraph.open();...barrier()
doesn't dedup. it bulks. https://tinkerpop.apache.org/docs/current/reference/#barrier-step i think the problem here is that unique Edge
properties bulk because of how equality works for them, where you can have two key/values that are the same but not refer to the same actual property. note that the same doesn't happen for vertex properties which have quality based on id
:
```gremlin> g.addV().property('name','alice')
==>v[0]
gremlin> g.addV().property('name','alice')
==>v[2]...Authorization with transaction results in error
:remote close
, the following error happens:
java.util.concurrent.ExecutionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to authorize: This AuthorizationHandler only handles requests with OPS_BYTECODE or OPS_EVAL.
java.util.concurrent.ExecutionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to authorize: This AuthorizationHandler only handles requests with OPS_BYTECODE or OPS_EVAL.
gtx.addV().property('name', 'test1').property('age', 11).iterate()
. The error you are seeing with "This AuthorizationHandler..." occurs after the transaction attempts to commit so it shouldn't actually prevent the commit from occurring. The real p...Is the insertion order guaranteed with this example code?
Promise.all
if for some reason the insertion order is important, then you need to call sequentially
gtx.addV("person").property("name", "jorge").iterate();
gtx.addV("person").property("name", "josh").iterate();
...Using mergeE to create an edge with an id that depends on a lookup
Is tx.close() necessary in Javascript?
https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-transactions https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-gremlin-transactions.html...
Using dedup with Neptune
dedup()
any more performant in that sort of query with Neptune's current implementation.As far as pagination goes, have you tried using Neptune's Query Results Cache instead of making multiple
range()
calls? That would significantly decrease latency for subsequent calls as you paginate across the resuls: https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-results-cache.html...`next(n)` with Gremlin JavaScript
next(n)
seems perfect, but it doesn't appear to be available for JavaScript as per the documentation.
Is there a reason for this limitation?...
Traversal Inspection for properties used
Gremlin with AWS Neptune
TraversalInterruptionTest taking a very long time to complete
Running Tinkerpop test in Janusgraph repo
configure gremlin-server to use remote Neptune server?
Query optimisation
Without any additional context I would take a guess that most of the difference in time is being spent doing
has("account", "id", "my_account")
since the first version is doing that filter twice....Combine two queries to perform only one
union
step https://tinkerpop.apache.org/docs/current/reference/#union-step
something like
g.union(
V().hasLabel('Groups').range({start_index}, {end_index}).elementMap(), V().hasLabel('Groups').out().range({start_index}, {end_index}).elementMap()))
...compatibility with Apache Jena Fuseki
Is the first traversal pattern evaluated by Match well defined
.mergeV() with Javascript not working