I want to find all vertecies which has an edge to a specific vertex but the vertex should also have an edge back to the other vertex.
The following query does not behave in the way i want, it seems that bothE() means either in or out or both, not explicitly that both an incoming and outgoing edge must be present.
g.V(id).bothE().outV()
I also don't want the starting vertex (g.v(id)) to be returned. I've looked through the documentation but there's so many complex queries available that it'll take me a very long time to find this one simple thing i need. Any help is appreciated
You need something like this
g.V(id).as('a').out().where(out().as('a'))
Which basically says, find everything I am connected to by an outgoing edge that also has an outgoing edge back to me.
Related
I have a scenario where I may need to update the from/to vertex of an already existing edge. I dont think there is any mechanism in gremlin to do so. So, what would be an ideal approach to achieve such functionality? What I can think of is -
Assuming To Vertex changes over time in an edge, Make sure the Edge ID is unique something like "From-Relationshipname"
While adding new edges check if Edge is already present then drop old Edge using the EdgeId and create a new one
Is it an efficient way?
Check the following recipe published in Gremlin docs for moving an edge.
The "marko" vertex contains a "knows" edge to the "vadas" vertex. The following code shows how to "move" that edge to the "peter" vertex in a single traversal:
g.V().has('name','marko').as('a').
outE('knows').as('e1').filter(inV().has('name','vadas')).
V().has('name','peter').
addE('knows').from('a').as('e2').
sideEffect(select('e1').properties().
unfold().as('p').
select('e2').
property(select('p').key(), select('p').value())).
select('e1').drop()
Source: https://tinkerpop.apache.org/docs/current/recipes/#edge-move
I want to use AQL to traverse a graph,I start from a vertex, I don't know how many layers of relationships, I want to go through the end,I want this traversal not to be influenced by direction,Is there any way to do it?Thank you for coming to help me.
Following edges in both, inbound and outbound direction, can be achieved with ANY. Unlimited traversal depth is not directly supported, but you can use an arbitrary high number for the maximum depth.
The same question was answered on GitHub by Simran-B.
I am planing to use ArangoDB and I am faced with a problem I don't know how to solve. I would like to do simple traversals but in my case but there are two requirements that I don't know how to solve:
I will not know in advance the type of vertices than an edge will connect to. I want to be able to connect edge of one type to any vertex on any side.
For one vertex, I want to retrieve all connected vertices (depth 1) no matter the edge type.
For the requirement 1, an example would be a Tag vertex (to tag some entity with some information) and I want to be able to tag any vertex using i.e. HasTag edge in a named graph. From what I currently see is that I need to define the "From" collections ("To" collection is the Tag collection) and this is limited to 10 collections. Since I could have 100 or more From collections I don't see how to solve this with named graphs.
Option would be to use anonymous graphs but then I have a problem in the second requirement. I also want to have an option, when given a vertex, to find all connected vertices (depth = 1) no matter the type of an edge. In an anonymous graph I would need to specify all of the edge collections in a query and again, there could be 100 or more of them. I don't know if there is a limit to this number but I would assume there is one - maybe I'm mistaken since I haven't yet tried it out.
Has anyone any idea how to solve this with ArrangoDB? I really like the database but I would like it to be more "typeless", that is, that I wouldn't have to define the type of vertex collection an edge can connect to.
Best regards
Tomaz
You can have more than 10 vertex collections in a named graph. The limitation of 10 only exists in the webUI. Creating the named graph over the ArangoShell or the server console will work.
How to change multiplicity of an edge in TitanDb? I've got an edge set to ONE2MANY but need to change it to MULTI.
Not possible.
When an edge is marked as unique - ONE2MANY or MANY2ONE , its raw data (as stored internally by Titan on the backend, for example, HBase) is different than non-unique ones, such as edges marked as MULTI.
So even if you make Titan consider your edges as MULTI ones, it will fail parsing the old ones which were once unique.
Ideally you would like to migrate the old data to the new form, but as far as I am concerned, there is no standard way to do it. The only solution is to re-insert the edges.
I have been tinkering with Graphs for some time, with the objective that I implement appropriate portions of the server-side stack using them. I have used Scala-Graph and Neo4J, and I am learning Spark GraphX. In almost all the applications I have implemented, the model has been that of a Property Graph (Node -> Edge -> Node, with attributes).
When designing the graph (DAGs to be precise), if I spot a strong and directed relationship between two nodes, I set up an edge from one node to one node. This is obvious and intuitive. If a Person likes a Site, an edge with property 'likes' connects them. Thus:
[Nirmalya] -- (Likes) --> [StackOverFlow]
[John] -- (Likes) --> [StackOverFlow]
[Ted] -- (Likes) --> [GoogleGroups ]
[Nirmalya] -- (Likes) --> [Neo4J]
Now, using outgoing edges, I can easily find out which sites Nirmalya likes.
But, when I want to find out who else likes what Nirmalya likes (i.e.,John), I tend to think that I should create an edge from Site-type Node to Person-type Node also (with property 'isLikedBy'), so that the path is obvious and the traversal is intuitive. Every Person and Site must be connected in both the directions, so that I can reach the other from either to answer queries like this one.
[Nirmalya] -- (Likes) --> [StackOverFlow] -- (IsLikedBy) --> [John]
But from many examples given by experts, I see that this is not prescribed. Instead, this is achieved by making use of operators like incoming. In other words, if two Nodes have an edge set up between them, I don't need to set both the directions of the edge explicitly (just 'likes' is sufficient, 'isLikedBy' is superfluous). Implementation of adjacency matrix makes this possible perhaps but I get a bit confused because I am being allowed to derive a contra-direction even when that direction is not explicit in the DAG.
My question is where is the gap in my understanding? Is it that 'IsLikedBy' direction should ideally be present, but we are optimizing? Alternatively, is it that there can be UseCases where such bidirectional edges are necessary and I need to spot them? Am I completely missing a theoretical underpinning?
I will be glad to become wiser.
I think it depends on the software. I can speak for Neo4j, but not for the other tools that you mentioned ;)
In Neo4j relationships are designed to be traversable both forwards and backwards without a performance cost. This applies both to traversing in the Java APIs as well as using Cypher. You can query both specifying a direction of incoming/outgoing as well as querying for relationships without concern for the direction and it should also be the same performance characteristics.