mergeV/E(Map|Traversal search).
option(Merge.onCreate, Map|Traversal).
option(Merge.onMatch, Map|Traversal)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
host = "localhost" | |
requests = 10000 | |
cluster = Cluster.open() | |
g = traversal().withRemote(DriverRemoteConnection.using(cluster)) | |
println("vertices at start: " + g.V().count().next()) | |
println("edges at start: " + g.E().count().next()) | |
start = System.currentTimeMillis() | |
(0..<50000).each{ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://groups.google.com/g/gremlin-users/c/6EXYq2Howdo/m/hST6BW97AgAJ | |
The reason properties on properties makes sense for vertices and not for | |
edges is rooted in database design and not logical semantics. | |
A property on a vertex is a record as is an edge in the database sense. | |
Hence, we have use cases where we want to know who added a property on a | |
vertex (as a record). | |
For edges, the property on the edge is not a record and thinking about it | |
as such would make the data model really complex (because you could then | |
get recursively more complex). Hence, all properties of the edge are part |
OlderNewer