Deleting all edges to a vertex and the vertex itself - graph-databases

I am trying to write a gremlin expression that will, for a given vertex, delete all the edges to and from it, and then delete the vertex itself.
I am using OrientDB 1.3-SNAPSHOT as my graph database.
This is my expression so far:
//The #8:1 just refers to a vertex
g.v('#8:1').bothE.each{ g.removeEdge(it) }.back(2)
I am expecting the above to delete the edges and then back 2, which should print out the node #8:1. However, for some reason, I am getting this error:
Error: java.lang.NullPointerException
Why is this happening?
Finally, how do I go about removing the vertex? The docs showed that removeVertex() requires an argument (which is the vertex). How do I pass the vertex from back(2) into removeVertex()?

Gremlin actually deletes all the edges for you if you delete the vertex. In my case, I simply had to do:
g.removeVertex(g.v('#8:1')); g.stopTransaction(SUCCESS);
This will delete the vertex and any edges that are associated with the vertex. Stop transation is required for gremlin to commit the change.
Now, as for why an error was thrown in the query for my statement. This is because each{} is a grovvy construct, so we exit the pipe. To continue in the pipe, use sideEffect{} instead.

Related

Is it possible to construct an adjacency matrix for a graph without storing indexes of nodes

I have managed to implement the solution with storing an index of each node, but is it possible to it without the indexes? My assignment is to implement a bloxrolz game, sort of. In the example I'm about to show you, I am out of ideas how to write code for checking if two nodes are adjacent to one another.
This is just a random field for the game. When reading from a file, I store every charachter here in a linked list, with a x,y coordinate and ID(if the char is not '-'). Only those that are not "-" are to be stored in a adjacency matrix since they represent the playground and "-" are nodes that could be changed to "-".
I have successfully implemented a solution in a way that I'm not sure if its legitimate or not. Can you help me figure out how to do this without the indexes.
An adjacency matrix is by definition a square matrix where each node is represented by a row and a column. If the entry at row i and column j is 1 (or some value you pick), then those two nodes are connected in the graph. Therefore, you need some way to map rows and columns to nodes and vice versa. Putting the nodes in a list and using each node's index in the list is one way to do that, but it's not the only way. You could give each node an ID number and, as long as each node's ID is unique and within the bounds of the matrix, you can use that. You could store a pointer to the corresponding node at the beginning or end of each row and column. In short, any method that lets you find the entries in the matrix for a given pair of nodes is sufficient.
That said, because you're talking about ordered lists of rows and columns, any method you pick will be similar to putting the nodes in a list and using the index of a node in the list. Think hard about what problem you're actually trying to solve.

How to set a vertex's Index myself in Titan Graph Database

The thing is that whenever I add a vertex with "addVertex()" command, the index of the vertex is chosen randomly like V[0] and the second time is V[2] and so on. I want to set it myself...How can I do it?
So that is not the index of your vertex. It is the id of your vertex, and if you asking how can you set that, then the answer is that you can't. Titan sets the Ids internally and they are immutable.
What you can do however, is create your own index so you can do fast lookups. I would recommend starting with simple composite index.
You can create a composite index as follows:
graph = TitanFactory.open('conf.properties');
mgmt = graph.openManagement();
myId = mgmt.makePropertyKey("MY-ID").dataType(String.class).make();
mgmt.buildIndex('byMyID', Vertex.class).addKey(myId).buildCompositeIndex();
mgmt.commit();
The above will create a property called MY-ID and index it. Which means that any vertex with that property can be looked up quickly.
Side Note: Make sure you are initialising a Titan Graph not a Tinker Graph. Tinker Graphs do not support indexing.

Import sparse matrix from .csv directly into graph using neo4j and cypher

I've got a small directed graph stored in a .csv as a sparse matrix. The file comprises 2 columns in the following format:
1,2
2,3
1,3
1,4
2,5
3,4
3,5
4,5
Every row is basically an adjacency relation between two nodes: 1->2, 2->3, 1->3, etc. I want to import this data into neo4j and create a graph (as a first step it can be an undirected graph).
I tried the following Cypher code:
LOAD CSV FROM 'file:///dummy.csv' AS line
CREATE((:node {`name`:line[1]})-[:`connects`]->(:node {`name`:line[2]}))
This is the furthest I've gone so far, but the results are not what I want. I'm reading the file into neo4j but I'm only getting multiple small graphs composed of two nodes with many node duplicates. My aim is to read every line as an adjacency relation and add connections to existing nodes without producing node duplications. Also, I would ideally like to display the name property of each node on top of itself (instead of node id) during graph visualisation. Your help is appreciated.
You should use MERGE to avoid creating duplicate nodes and relationships:
LOAD CSV FROM 'file:///dummy.csv' AS line
MERGE (a:node {name:line[0]})
MERGE (b:node {name:line[1]})
MERGE (a)-[:connects]->(b);
Also, see the documentation for how to style the browser visualization.

Traverse directed edges recursively with OrientDB

I am trying to recursively traverse outbound edges from a given node, but not the inbound ones. I want both out edges and out vertices in the result of my query.
In the following graph, starting from (a), I need (a), (b), (c), (d), (e), including the edges, but not the part after (c), which is <-- (x)
(a) --> (b) --> (c) <-- (x)
˙--> (d) --> (e)
If I try doing the following, then it traverses everything recursively, irrespective of edge direction, thus also returning (x):
TRAVERSE * FROM (SELECT FROM a) LIMIT -1`
If I dont traverse *, butoutE()`, it only retrieves the starting node and its direct neighbours: (a), (b), (d), so it does not do recursion.
traverse outE() from (SELECT FROM a) LIMIT -1
I also tried to follow the documentation at here, and traversed V.out, E.in but it only returns (a) without traversing.
traverse V.out, E.in from (SELECT FROM a) LIMIT -1`
Also tried playing with variants, like WHILE $depth < 10, but that hasn't made any difference and now I'm stuck.
Running OrientDB 2.0.12
Graph :
Traversal query to get only the outgoing edges recursively starting from #33:289990 :
traverse out('IsFriendsWith') from #33:289990
Traversal query to get more then one edge class outgoing vertices recursively :
traverse out('IsFriendsWith'), out('secondEdgeClassName') from #33:289990
Traversal query to get the edge and vertex instances recursively :
traverse out('IsFriendsWith'), outE('IsFriendsWith') from #33:289990

OpenGL 2.1 Draw object with different buffers index

I'm dealing with OBJ file with OpenGL 2.1. This is OBJ spec: http://www.martinreddy.net/gfx/3d/OBJ.spec
According to that, a face is indicated as vertex/texture/normal where vertex, texture and normal are different, this mean index of vertex, texture coordinate and normal index in each buffers are different.
Question: How can i draw an object that supply different indicate buffers for each vertex, texture and normal arrays?
Sad answer, this is not possible in OpenGL. In OpenGL (and many other such systems, especially Direct3D), a vertex is conceptually the union of all the vertex attributes, like position, normal or texture coordinates (it's unfortunate that the term vertex is often used only for the position attribute). So two vertices with the same position but different normal vectors are conceptually two different vertices.
That's the reason, why you have to use the same vertex index for all attributes. So to draw an .OBJ file with OpenGL or similar libraries, you won't get around processing the data after loading.
The easiest way is to completely drop indices and just store all vertex data for each triangle corner one after the other, using the indices read from the face specification, thus having 3*F vertices and no indices. This, however is rather inefficient, since you probably still have many duplicate vertices, even if considering all attributes at a whole.
Another option is to insert the index triples (comprised of vertex, texcoord and normal index) into a hash table and map it to a combined index. Whenever the index triple already exists, you replace it by the one index in the hash table and when it doesn't exist, you add a new vertex (comprised of position, normal and texCoords) to your final rendered vertex arrays, indexing the file's vertex arrays using the index triple (and insert this new vertex array size as unique index into the hash table, of course).

Resources