Skip to content

Latest commit

 

History

History
135 lines (85 loc) · 4.83 KB

SQL-Create-Edge.md

File metadata and controls

135 lines (85 loc) · 4.83 KB
search
keywords
SQL
command
create
edge
CREATE EDGE

SQL - CREATE EDGE

Creates a new edge in the database.

Syntax

CREATE EDGE <class> [CLUSTER <cluster>] 
FROM <rid> | ( <query> ) | [ <rid> (, <rid>)* ] 
TO <rid> | ( <query> ) | [ <rid> (, <rid>)* ] 
[ SET <field> = <expression>[,]* ] | CONTENT {<JSON>}
[RETRY <retry> [WAIT <pauseBetweenRetriesInMs]] [BATCH <batch-size>]
  • <class> Defines the class name for the edge. Use the default edge class E in the event that you don't want to use sub-types.
  • <cluster> Defines the cluster in which you want to store the edge.
  • JSON Provides JSON content to set as the record. Use this instead of entering data field by field.
  • RETRY Define the number of retries to attempt in the event of conflict, (optimistic approach).
  • WAIT Defines the time to delay between retries in milliseconds.
  • BATCH Defines whether it breaks the command down into smaller blocks and the size of the batches. This helps to avoid memory issues when the number of vertices is too high. By default, it is set to 100. This feature was introduced in version 2.1.3.

Edges and Vertices form the main components of a Graph database. OrientDB supports polymorphism on edges. The base class for an edge is E.

Beginning with version 2.1, when no edges are created OrientDB throws a OComm andExecutionException error. This makes it easier to integrate edge creation in transactions. In such cases, if the source or target vertices don't exist, it rolls back the transaction. (Prior to 2.1, no such error is thrown.)

Examples

  • Create an edge of the class E between two vertices:

    orientdb> CREATE EDGE FROM #10:3 TO #11:4
    
  • Create an edge of the class E between multiple vertices:

    orientdb> CREATE EDGE FROM [#10:3, #10:4] TO [#11:4, #11:5] 
    
  • Create a new edge type and an edge of the new type:

    orientdb> CREATE CLASS E1 EXTENDS E
    orientdb> CREATE EDGE E1 FROM #10:3 TO #11:4
    
  • Create an edge in a specific cluster:

    orientdb> CREATE EDGE E1 CLUSTER EuropeEdges FROM #10:3 TO #11:4
    
  • Create an edge and define its properties:

    orientdb> CREATE EDGE FROM #10:3 TO #11:4 SET brand = 'fiat'
    
  • Create an edge of the type E1 and define its properties:

    orientdb> CREATE EDGE E1 FROM #10:3 TO #11:4 SET brand = 'fiat', name = 'wow'
    
  • Create edges of the type Watched between all action movies in the database and the user Luca, using sub-queries:

    orientdb> CREATE EDGE Watched FROM (SELECT FROM account WHERE name = 'Luca') TO 
              (SELECT FROM movies WHERE type.name = 'action')
    
  • Create an edge using JSON content:

    orientdb> CREATE EDGE E FROM #22:33 TO #22:55 CONTENT { "name": "Jay", 
              "surname": "Miner" }
    

For more information, see

Control Vertices Version Increment

Creating and deleting edges causes OrientDB to update versions involved in the vertices. To avoid this behavior, use the Bonsai Structure.

By default, OrientDB uses Bonsai as soon as it reaches the threshold to optimize operation. To always use Bonsai on your database, either set this configuration on the JVM or in the orientdb-server-config.xml configuration file.

$ java -DridBag.embeddedToSbtreeBonsaiThreshold=-1

Alternatively, in your Java application use the following call before opening the database:

OGlobalConfiguration.RID_BAG_EMBEDDED_TO_SBTREEBONSAI_THRESHOLD.setValue(-1);

For more information, see Concurrency on Adding Edges.

NOTE When running a distributed database, the SB Tree index algorithm is not supported.

History

2.0

  • Disables Lightweight Edges in new databases by default. This command now creates a regular edge.

1.4

  • Command uses the Blueprints API. If you are in Java using the OGraphDatabase API, you may experience some differences in how OrientDB manages edges.

    To force the command to work with the older API, change the GraphDB settings, as described in Graph backwards compatibility.

1.2

  • Implements support for query and collection of Record ID's in the FROM...TO clause.

1.1

  • Initial version.