age
age copied to clipboard
how to add nodes and edges in RDB without a cypher query so that it will be same as cypher query
How to manually add nodes and edges in RDB so that it's looks like nodes or edges added through a cypher query
In order for you to add nodes and edges in a Relational Database without a cypher query, you need to modify the tables that represents the graph's structure
eg:
SELECT * FROM ag_label;
provides you with the table containing all your nodes, edges and relationships.
You can display the table of all the vertices in a particular graph by performing this query;
SELECT * FROM demo._ag_label_vertex;
, where demo
is my graph and ag_label_vertex
contains the vertices in my demo
graph
You should see something like this;
id | properties
------------------+------------------------------------------
281474976710657 | {"name": "Pete"}
281474976710659 | {"name": "Mike"}
2251799813685249 | {"city": "New York", "name": "Pete"}
2251799813685250 | {"city": "Toronto", "name": "Mike"}
2251799813685251 | {"city": "Vancouver", "name": "Clint"}
2251799813685252 | {"city": "Dallas", "name": "Jane"}
2251799813685253 | {"city": "San Francisco", "name": "Tom"}
2533274790395906 | {"city": "Houston", "name": "Hugh"}
(8 rows)
Now you can manually add nodes and edges to a graph without a cypher query by running the query;
INSERT INTO demo._ag_label_vertex(id, properties) VALUES ('2533274790395907', '{"name": "Mark"}');
If you run SELECT * FROM demo._ag_label_vertex;
again, you notice that the {"name": "Mark"}
has been added to the table.
id | properties
------------------+------------------------------------------
281474976710657 | {"name": "Pete"}
281474976710659 | {"name": "Mike"}
2533274790395907 | {"name": "Mark"}
2251799813685249 | {"city": "New York", "name": "Pete"}
2251799813685250 | {"city": "Toronto", "name": "Mike"}
2251799813685251 | {"city": "Vancouver", "name": "Clint"}
2251799813685252 | {"city": "Dallas", "name": "Jane"}
2251799813685253 | {"city": "San Francisco", "name": "Tom"}
2533274790395906 | {"city": "Houston", "name": "Hugh"}
(9 rows)
If you run the regular cypher query;
demo=# SELECT * FROM cypher('demo', $$
demo$# MATCH (u)
demo$# RETURN u
demo$# $$) as (u agtype);
u
-------------------------------------------------------------------------------------------------------------
{"id": 281474976710657, "label": "", "properties": {"name": "Pete"}}::vertex
{"id": 281474976710659, "label": "", "properties": {"name": "Mike"}}::vertex
{"id": 2533274790395907, "label": "employer", "properties": {"name": "Mark"}}::vertex
{"id": 2251799813685249, "label": "worker", "properties": {"city": "New York", "name": "Pete"}}::vertex
{"id": 2251799813685250, "label": "worker", "properties": {"city": "Toronto", "name": "Mike"}}::vertex
{"id": 2251799813685251, "label": "worker", "properties": {"city": "Vancouver", "name": "Clint"}}::vertex
{"id": 2251799813685252, "label": "worker", "properties": {"city": "Dallas", "name": "Jane"}}::vertex
{"id": 2251799813685253, "label": "worker", "properties": {"city": "San Francisco", "name": "Tom"}}::vertex
{"id": 2533274790395906, "label": "employer", "properties": {"city": "Houston", "name": "Hugh"}}::vertex
(9 rows)
You can still find {"name": "Mark"}
in the output.
This is not supported nor recommended behavior. Internal representation of a graph in AGE can change and anything relying on a particular format can break. You should be using existing commands to manipulate the graph data.
I also will not recommend the manual insertion of nodes and edges into graph tables, because the node's id
is automatically generated and inserting an id
manually could lead to loss of graph integrity.
As nodes and relationships are stored in tables, therefore you can use SQL's INSERT INTO statement to insert node or edges. But this approach is not recommended because you need to ensure that the inserted nodes and their relationships are consistent with the existing graph structure other wise it may destroy the overall structure and integrity of the graph.
You can manually add by simply adding using SQL insert queries, but this may result into overall inconsistency in relationships with the existing structure, that's why it is not recommended