Is it possible to get an example to upsert an edge in orientdb. IF it does not exist is there a way to check if the edge exist, if it does then just update the edge else create a new edge. I am using Orientdb 2.1.13 version.
Thank you
via SQL you can use the basic UPDATE command
update written_by SET out = #9:2, in = #16:43, prop="gianni" UPSERT WHERE out = #9:2 and in = #16:43
http://orientdb.com/docs/last/SQL-Update.html
When you use "update written_by SET out = #9:2, in = #16:43, prop="gianni" UPSERT WHERE out = #9:2 and in = #16:43", it doesn't work properly for edges: it will create edge if it doesn't exist, but it will not create in and out properties in vertex, so, for example, you will not able to query MATCH. It works this way cos “The UPDATE/UPSERT works at document level, so it doesn't create the connections from the vertices. Using it, you will have a broken graph”, as authors said.
But you can use “upsert” for edges since version 3.0.1 and it will work properly – but you need to do the following:
Create unique index on edge_class (out, in) and – it's strange – The order is important!
To do this, you need to create in and out properties first, otherwise db can't create index and there will be an exception when you will try to run command “Create index”.
Then, use command CREATE EDGE UPSERT FROM TO .
In this case edge will be created only if it is not exists, and it will create in and out properties for vertex classes.
Related
I am using pgrouting 2.1.0.
I have spatial and non-spatial data in different table(in different schema). Here I am creating a view which contain geom(filled), id(filled) source(blank) and target(blank).
I have tried pgr_createTopology() function but on view it is running as it requires table. Also tried to write query in pgr_createtopology() but not succeeded. Can any one suggest other option.
I can not merge spatial and non-spatial data.
First of all update your pg_routing version as pgr_createTopology() won't run on view for your version. I have used 2.6.0. Next you have to create editable view of your spatial and non-spatial data. This can be done by applying rules to your view. You might be wanting to update source and target columns by running pgr_createTopology() So create a rule like following for your view. Hope that works.
CREATE OR REPLACE RULE update_vv1 AS
ON UPDATE TO view_schema_name.view_table_name
DO INSTEAD
(
UPDATE schema_non_spatial_table.non_spatial_table_name SET source = new.source, target = new.target
WHERE non_spatail_table_name.id = old.id;
);
UPDATE GeoAgentSummary set out = #45:0, in = #21:0, _2015 = sum(_2015, 10.0f) upsert where out = #45:0 and in = #21:0
I am using the above query to either create an edge (if it is not there) or update an existing edge if it already exists in OrientDB
An edge is created between #45:0 and #21:0.
But in Agent(vertex class having clusters 45, 46, 47 and 48) i.e. in #45:0 it is not showing any outgoing edges.
Agent Class a vertex class
I know that this question is three years old, but for somebody else who will google it further:
You can use “upsert” for edges since version 3.0.1 and it will work properly – but you need to do the following:
Create unique index on edge_class (out, in) and – it's strange – The order is important!
To do this, you need to create in and out properties first, otherwise db can't create index and there will be an exception when you will try to run command “Create index”.
Then, use command CREATE EDGE UPSERT FROM TO .
In this case edge will be created only if it is not exists, and it will create in and out properties for vertex classes.
But it still doesn't work for UPDATE command 'cos, as authors said, “The UPDATE/UPSERT works at document level, so it doesn't create the connections from the vertices. Using it, you will have a broken graph” and it still the same.
The UPDATE command acts like a normal document update without taking care of keeping the edge-vertex "synchronization". To do that you'd have to use the UPDATE EDGE that, however, doesn't support the UPSERT.
There is on open issue on github about that https://github.com/orientechnologies/orientdb/issues/4436
Read also this https://github.com/orientechnologies/orientdb/issues/1114
I'm new to Titan and looking for the best way to iterate over the entire set of vertices with a given label without running out of memory. I come from a strong SQL background so I am still working on switching my way of thinking away from SQL-type thinking. Let's say I have 1 million profile vertices. I would like to iterate over each one and perform some type of statistical analysis of the information linked to each profile. I don't really care how long the entire analysis process takes, but I need to iterate over all of the profiles. In SQL I would do SELECT * FROM MY_TABLE, using a scroll-sensitive result, fetch the next result, grab and process the info linked to that row, then fetch the next result. I also don't care if the result is real-time accurate as it is just for gathering general stats, so if a new profile is added during iteration and I miss it, that's ok.
Even if there is a way to grab all the values for a given property, that would probably work too because then I could go through that list and grab each vertex by its ID for example.
I believe titan does lazy loading so you should be able to just iterate over the whole graph:
GraphTraversal<Vertex, Vertex> it = graph.traversal().V();
while(it.hasNext()){
Vertex v = it.next():
//Do what you want here
}
Another option would be to use the range step so that you explicitly choose the range of vertices you need. For example:
List<Vertex> vertices = graph.traversal().V().range(0, 3).toList();
//Do what you want with your batch of vertices.
With regards to getting vertices of a specific type you can query vertices based on their internal properties. For example if you have and internal property "TYPE" which defined the type you are interested in. You can query for those vertices by:
graph.traversal().V().has("TYPE", "A"); //Gets vertices of type A
graph.traversal().V().has("TYPE", "B"); //Gets vertices of type B
Background
I have a model represented by a graph in OrientDB. The model consists of a few classes, among others A and B. The classes are connected with a relation has as an edge from A to B. The edge also connects A to other classes:
A ---has--> B
A ---has--> C
Problem
I want to update a property of B if it has a has edge to an A with a given RecordID.
My Solution
Currently I am selecting the target/out vertex of all edges has that are of class B starting at a given RecordID. This works but feels like I am missing an easier solution to this.
UPDATE (SELECT expand(out('has')[#class = 'B']) FROM #11:1) SET prop = true
I also tried the following, which did not work as I expected:
UPDATE B SET prop = true WHERE in('has').#rid = #11:1
My Question
Is there a simpler solution than an UPDATE with SUBSELECT?
I don't think there is any premade sql function that does this kind of filtering in an update.
Your first query is the way to go because it traverses instead of filtering on all the vertices. Yes, you have a subquery but it is faster then using a where in the update statement.
It would be cool to have a syntax like this :
update #9:1.inV('edgeClassName')[#class='className'] set prop = true
We have to use a subquery for this to work. It feels natural to me.
If I create an index according to the docs (http://s3.thinkaurelius.com/docs/titan/0.5.4/indexes.html) without making it unique is it possible to make it unique after? I have not added any vertices or edges to the graph, just created the index.
Something like:
index = mgmt.getGraphIndex('name')
index.unique()
I am using the Gremlin console to make these changes.
Is it possible to do this somehow?
This is a documented limitation of Titan.
Ref : http://s3.thinkaurelius.com/docs/titan/0.5.0/limitations.html
section - 14.2.1. Unable to Drop Indices
Since no vertices or edges are added to graph, try the below gremlin command.
g.V.remove() or g.V.each{g.removeVertex(it)}
g.commit()
Then try to create the indexes again with .unique().
If still unable to re-create the indices, try to clean storage-backend.
In case of cassandra "DROP Keyspace titan;"
This must definitely work,I have tried in Titan 0.4 and worked.