Category: orientdb

OrientDB – Useful Resources ”; Previous Next The following resources contain additional information on OrientDB. Please use them to get more in-depth knowledge on this. Useful Video Courses Oracle DB Online Training Course 42 Lectures 8.5 hours Tutorialspoint More Detail Oracle DB 12c Online Training 34 Lectures 7 hours Tutorialspoint More Detail AWS Certified Database Specialty Exam Prep Training (DBS-C01) Most Popular 73 Lectures 7.5 hours Total Seminars More Detail Cosmos DB Training Course 31 Lectures 1 hours Skillbakery More Detail Mongo DB Course: Learn all about MongoDB Best Seller 71 Lectures 2.5 hours Skillbakery More Detail Full-Stack web app development with Angular 12, .NET Core Web API & Mongo DB Most Popular 20 Lectures 49 mins Vinay Kumar More Detail Print Page Previous Next Advertisements ”;

OrientDB – Hooks ”; Previous Next OrientDB Hooks are nothing but triggers in the database terminology that enable internal events before and after each CRUD operations in the user applications. You can use hooks to write custom validation rules, to enforce security, or to arrange external events like replicating against a relational DBMS. OrientDB supports two kinds of hooks − Dynamic Hook − Triggers, which can be built at class level and/or Document level. Java (Native) Hook − Triggers, which can be built using Java classes. Dynamic Hooks Dynamic hooks are more flexible than Java hooks, because they can be changed at runtime and can run per document if needed, but are slower than Java hooks. To execute hooks against your documents, first allow your classes to extend OTriggered base class. Later, define a custom property for the interested event. Following are the available events. onBeforeCreate − Called before creating a new document. onAfterCreate − Called after creating a new document. onBeforeRead − Called before reading a document. onAfterRead − Called after reading a document. onBeforeUpdate − Called before updating a document. onAfterUpdate − Called after updating a document. onBeforeDelete − Called before deleting a document. onAfterDelete − Called after deleting a document. Dynamic Hooks can call − Functions, written in SQL, Javascript or any language supported by OrientDB and JVM. Java static methods. Class Level Hooks Class level hooks are defined for all the documents that relate to a class. Following is an example to set up a hook that acts at class level against Invoice documents. CREATE CLASS Invoice EXTENDS OTriggered ALTER CLASS Invoice CUSTOM onAfterCreate = invoiceCreated Let”s create the function invoiceCreated in Javascript that prints in the server console the invoice number created. CREATE FUNCTION invoiceCreated “print(”\nInvoice created: ” + doc.field (”number”));” LANGUAGE Javascript Now try the hook by creating a new Invoice document. INSERT INTO Invoice CONTENT {number: 100, notes: ”This is a test} If this command is executed successfully, you will get the following output. Invoice created: 100 Document Level Hook You can define a special action only against one or more documents. To do this, allow your class to extend OTriggered class. For example let us execute a trigger, as Javascript function, against an existent Profile class, for all the documents with property account = ”Premium”. The trigger will be called to prevent deletion of documents. ALTER CLASS Profile SUPERCLASS OTriggered UPDATE Profile SET onBeforeDelete = ”preventDeletion” WHERE account = ”Premium” Let”s create the preventDeletion() Javascript function. CREATE FUNCTION preventDeletion “throw new java.lang.RuntimeException(”Cannot delete Premium profile ” + doc)” LANGUAGE Javascript And then test the hook by trying to delete a ‘Premium’ account. DELETE FROM #12:1 java.lang.RuntimeException: Cannot delete Premium profile profile#12:1{onBeforeDelete:preventDeletion,account:Premium,name:Jill} v-1 (<Unknown source>#2) in <Unknown source> at line number 2 JAVA Hooks One common use case for OrientDB Hooks (triggers) is to manage created and updated dates for any or all classes. For example, you can set a CreatedDate field whenever a record is created and set an UpdatedDate field whenever a record is updated, and do it in a way where you implement the logic once at the database layer and never have to worry about it again at the application layer. Before creating, you will have to download orientdb-core.jar file by visit the following link download OrientDB core. And later copy that jar file into the folder where you want to store the Java source file. Create Hook File Create a Java file named HookTest.java, which will test the Hook mechanism using Java language. import java.io.BufferedReader; import java.io.FileNotFoundException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.StringReader; import java.util.ArrayList; import java.util.List; import java.util.concurrent.locks.ReentrantLock; import com.orientechnologies.orient.core.hook.ODocumentHookAbstract; import com.orientechnologies.orient.core.hook.ORecordHook; import com.orientechnologies.orient.core.hook.ORecordHookAbstract; import com.orientechnologies.orient.core.db.ODatabaseLifecycleListener; import com.orientechnologies.orient.core.db.ODatabase; import com.orientechnologies.orient.core.record.ORecord; import com.orientechnologies.orient.core.record.impl.ODocument; public class HookTest extends ODocumentHookAbstract implements ORecordHook { public HookTest() { } @Override public DISTRIBUTED_EXECUTION_MODE getDistributedExecutionMode() { return DISTRIBUTED_EXECUTION_MODE.BOTH; } public RESULT onRecordBeforeCreate( ODocument iDocument ) { System.out.println(“Ran create hook”); return ORecordHook.RESULT.RECORD_NOT_CHANGED; } public RESULT onRecordBeforeUpdate( ODocument iDocument ) { System.out.println(“Ran update hook”); return ORecordHook.RESULT.RECORD_NOT_CHANGED; } } The above sample code prints the appropriate comment every time you create or update a record of that class. Let”s add one more hook file setCreatedUpdatedDates.java as follows − import java.io.BufferedReader; import java.io.FileNotFoundException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.StringReader; import java.util.ArrayList; import java.util.List; import java.util.concurrent.locks.ReentrantLock; import com.orientechnologies.orient.core.hook.ODocumentHookAbstract; import com.orientechnologies.orient.core.hook.ORecordHook; import com.orientechnologies.orient.core.hook.ORecordHookAbstract; import com.orientechnologies.orient.core.db.ODatabaseLifecycleListener; import com.orientechnologies.orient.core.db.ODatabase; import com.orientechnologies.orient.core.record.ORecord; import com.orientechnologies.orient.core.record.impl.ODocument; public class setCreatedUpdatedDates extends ODocumentHookAbstract implements ORecordHook { public setCreatedUpdatedDates() { } @Override public DISTRIBUTED_EXECUTION_MODE getDistributedExecutionMode() { return DISTRIBUTED_EXECUTION_MODE.BOTH; } public RESULT onRecordBeforeCreate( ODocument iDocument ) { if ((iDocument.getClassName().charAt(0) == ”t”) || (iDocument.getClassName().charAt(0)==”r”)) { iDocument.field(“CreatedDate”, System.currentTimeMillis() / 1000l); iDocument.field(“UpdatedDate”, System.currentTimeMillis() / 1000l); return ORecordHook.RESULT.RECORD_CHANGED; } else { return ORecordHook.RESULT.RECORD_NOT_CHANGED; } } public RESULT onRecordBeforeUpdate( ODocument iDocument ) { if ((iDocument.getClassName().charAt(0) == ”t”) || (iDocument.getClassName().charAt(0)==”r”)) { iDocument.field(“UpdatedDate”, System.currentTimeMillis() / 1000l); return ORecordHook.RESULT.RECORD_CHANGED; } else { return ORecordHook.RESULT.RECORD_NOT_CHANGED; } } } What the above code does is look for any class that starts with the letters ‘r’ or ‘t’ and sets CreatedDate and UpdatedDate when the record gets created and sets just UpdatedDate every time the record gets updated. Compile Java Hooks Compile Java code by using the following command. Note: Keep the downloaded jar file and these Java files into the same folder. $ jar cf hooks-1.0-SNAPSHOT.jar *.java Move Compiled Code to Where OrientDB Server Can Find It You need to copy the finished .jar file to the directory where your OrientDB server will look for them. This means the ‘./lib’ folder under your OrientDB Server root directory will look like this − $ cp hooks-1.0-SNAPSHOT.jar “$ORIENTDB_HOME/lib” Enable Test Hook in the OrientDB Server Configuration File Edit $ORIENTDB_HOME/config/orientdb-server-config.xml and add the following section near the end of the file. <hooks> <hook class = “HookTest” position = “REGULAR”/> </hooks> … </orient-server> Restart OrientDB Server Once you restart OrientDB Server, the hook you defined in orientdb-server-config.xml is now active. Launch an OrientDB console, connect it to your database, and run the following command − INSERT INTO V SET ID = 1; If this command is executed successfully, you

OrientDB – Transactions ”; Previous Next Like RDBMS, OrientDB supports transactions ACID properties. A transaction comprises a unit of work performed within a database management system. There are two main reasons to maintain transactions in a database environment. To allow concurrent recovery from failures and keep a database consistent even in case of system failures. To provide isolation between programs accessing a database concurrently. By default, the database transaction must follow ACID properties such as Atomic, Consistent, Isolated, and Durable properties. But OrientDB is an ACID compliant database, which means it does not contradict or negate the concept ACID, but it changes its perception while handling the NoSQL database. Take a look at how ACID properties work along with NoSQL database. Atomic − When you do something to change the database the change should work or fail as a whole. Consistent − The database should remain consistent. Isolated − If other transaction executions are executing at the same time, then the user will not be able to see the records in concurrent execution. Durable − If the system crashes (hardware or software), the database itself should be able to take a backup. Database transaction can be achieved by using Commit and Rollback commands. Commit Commit means closing the transaction by saving all changes to the database. Rollback means recover the database state to the point where you opened the transaction. The following statement is the basic syntax of the COMMIT database command. COMMIT Note − You can use this command only after connecting to a particular database and after beginning the transaction. Example In this example, we will use the same database named ‘demo’ that we created in an earlier chapter of this tutorial. We will see the operation of commit transaction and store a record using transactions. You need to first start the transaction using the following BEGIN command. orientdb {db = demo}> BEGIN Insert a record into an employee table with the values id = 12 and name = satish.P using the following command. orientdb> INSERT INTO employee (id, name) VALUES (12, ”satish.P”) You can use the following command to commit the transaction. orientdb> commit If this transaction successfully committed, you will get the following output. Transaction 2 has been committed in 4ms Rollback Rollback means recovering the database state to the point where you opened the transaction. The following statement is the basic syntax of the ROLLBACK database command. ROLLBACK Note − You can use this command only after connecting to a particular database and after beginning the transaction. Example In this example, we will use the same database named ‘demo’ that we created in an earlier chapter of the tutorial. We will see the operation of rollback transaction and store a record using transactions. You have to first start the transaction using the following BEGIN command. orientdb {db = demo}> BEGIN Insert a record into an employee table with the values id = 12 and name = satish.P using the following command. orientdb> INSERT INTO employee (id, name) VALUES (12, ”satish.P”) You can use the following command to retrieve the records of the table employee. orientdb> SELECT FROM employee WHERE name LIKE ”%.P” If this command is executed successfully, you will get the following output. —+——-+——————– # | ID | name —+——-+——————– 0 | 12 | satish.P —+——-+——————– 1 item(s) found. Query executed in 0.076 sec(s). You can use the following command to Rollback this transaction. orientdb> ROLLBACK Check the select query again to retrieve the same record from the Employee table. orientdb> SELECT FROM employee WHERE name LIKE ”%.P” If the Rollback is executed successfully, you will get 0 records found in the output. 0 item(s) found. Query executed in 0.037 sec(s). Print Page Previous Next Advertisements ”;

OrientDB – Python Interface ”; Previous Next OrientDB driver for Python uses the binary protocol. PyOrient is the git hub project name which helps to connect OrientDB with Python. It works with OrientDB version 1.7 and later. The following command is used to install PyOrient. pip install pyorient You can use the script file named demo.py to do the following tasks − Create a client instance means create a connection. Create DB named DB_Demo. Open DB named DB_Demo. Create class my_class. Create properties id, and name. Insert record into my class. //create connection client = pyorient.OrientDB(“localhost”, 2424) session_id = client.connect( “admin”, “admin” ) //create a databse client.db_create( db_name, pyorient.DB_TYPE_GRAPH, pyorient.STORAGE_TYPE_MEMORY ) //open databse client.db_open( DB_Demo, “admin”, “admin” ) //create class cluster_id = client.command( “create class my_class extends V” ) //create property cluster_id = client.command( “create property my_class.id Integer” ) cluster_id = client.command( “create property my_class.name String” ) //insert record client.command(“insert into my_class ( ”id”,”’name” ) values( 1201, ”satish”)”) Execute the above script using the following command. $ python demo.py Print Page Previous Next Advertisements ”;

OrientDB – Caching ”; Previous Next Caching is a concept that will create a copy of the database table structure providing a comfortable environment for the user applications. OrientDB has several caching mechanisms at different levels. The following illustration gives an idea about what caching is. In the above illustration DB1, DB2, DB3 are the three different database instances used in an application. Level-1 cache is a Local cache which stores all the entities known by a specific session. If you have three transactions in this session, it will hold all entities used by all three transactions. This cache gets cleared when you close the session or when you perform the “clear” method. It reduces the burden of the I/O operations between the application and the database and in turn increases the performance. Level-2 cache is a Real cache that works by using third party provider. You can have full control over the contents of the cache, i.e. you will be able to specify which entries should be removed, which ones should be stored longer and so on. It is a full shared cache among multiple threads. Storage model is nothing but storage device that is disk, memory, or remote server. How Cache Works in OrientDB? OrientDB caching provides different methodologies in different environments. Caching is mainly used for faster database transactions, reducing the processing time of a transaction and increasing the performance. The following flow diagrams show how caching works in local mode and client-server mode. Local Mode (Embedded Database) The following flow diagram tells you how the record is in-between storage and used application in the local mode i.e., when your database server is in your localhost. When the client application asks for a record OrientDB checks for the following − If a transaction has begun, then it searches inside the transaction for changed records and returns it if found. If the local cache is enabled and contains the requested record, then returns it. If at this point the record is not in cache, then asks for it to the Storage (disk, memory). Client Server Mode (Remote Database) The following flow diagram tells you how the record is in-between storage and used application in the client-server mode i.e., when your database server is in remote location. When the client application asks for a record, OrientDB checks for the following − If a transaction has begun, then it searches inside the transaction for changed records and returns it if found. If the local cache is enabled and contains the requested record, then returns it. At this point, if the record is not in cache, then asks for it to the Server through a TCP/IP call. In the server, if the local cache is enabled and contains the requested record, then returns it. At this point, still the record is not cached in the server, then asks for it to the Storage (disk, memory). Print Page Previous Next Advertisements ”;

OrientDB – Delete Vertex ”; Previous Next Delete Vertex command is used to remove vertices from the database. While deleting, it checks and maintains the consistency with the edges and removes all cross-references (with the edges) to the deleted vertex. The following statement is the basic syntax of Delete Vertex Command. DELETE VERTEX <vertex> [WHERE <conditions>] [LIMIT <MaxRecords>>] [BATCH <batch-size>] Following are the details about the options in the above syntax. <vertex> − Defines the vertex that you want to remove, using its Class, Record ID, or through a sub-query. WHERE − Filters condition to determine which records the command removes. LIMIT − Defines the maximum number of records to be removed. BATCH − Defines how many records the command removes at a time, allowing you to break large transactions into smaller blocks to save on memory usage. Example Try the following command to learn how to delete single vertex or multiple vertices. Execute the following command to remove the vertex ‘#14:1’. orientdb> DELETE VERTEX #14:1 If the above command is executed successfully, you will get the following output. Delete record(s) ”1” in 0.005000 sec(s) Execute the following command to remove all vertices from the class ‘Customer’ marked with the property ‘isSpam’. orientdb> DELETE VERTEX Customer WHERE isSpam = TRUE If the above command is executed successfully, you will get the following output. Delete record(s) ”3” in 0.005000 sec(s) Print Page Previous Next Advertisements ”;

OrientDB – Delete Edge ”; Previous Next Delete edge command is used to remove the database. This is equivalent of the delete command, with the addition of checking and maintaining consistency with vertices by removing all cross-references to the edge from both ‘in’ and ‘out’ vertex properties. The following statement is the basic syntax of Delete Edge command. DELETE EDGE ( <rid> | [<rid> (, <rid>)*] | ( [ FROM (<rid> | <select_statement> ) ] [ TO ( <rid> | <select_statement> ) ] ) | [<class>] ( [WHERE <conditions>] [LIMIT <MaxRecords>] [BATCH <batch-size>] )) Following are the details about the options in the above syntax. FROM − Defines the starting point vertex of the edge to delete. To − Defines the ending point vertex of the edge to delete. WHERE − Defines the filtering conditions. LIMIT − Defines the maximum number of edges to delete. BATCH − Defines the block size for the operation. Example Try the following examples to learn how to delete edges. Execute the following query to delete the edge between two vertices (#11:2, #11:10). But there might be a chance that might exist one or more edges between two vertices. So that we are using the date property for proper functionality. This query will delete the edges which are created on ”2015-01-15” and later. orientdb {db = demo}> DELETE EDGE FROM #11:2 TO #11:10 WHERE date >= “2012-01-15″ If the above query is executed successfully, you will get the following output. Delete record(s) ”2” in 0.00200 sec(s) Execute the following query to delete edges starting from the vertex ‘#11:5’ to the vertex ‘#11:10’ and which are related to ‘class = Customer’. orientdb {db = demo}> DELETE EDGE FROM #11:5 TO #11:10 WHERE @class = ”Customer” If the above query is executed successfully, you will get the following output. Delete record(s) ”2” in 0.00200 sec(s) Print Page Previous Next Advertisements ”;

OrientDB – Performance Tuning ”; Previous Next In this chapter, you can get some general tips on how to optimize your application that uses OrientDB. There are three ways to increase the performance for different types of database. Document Database Performance Tuning − It uses a technique that helps avoid document creation for every new document. Object Database Performance Tuning − It uses the generic techniques to improve performance. Distributed Configuration Tuning − It uses different methodologies to improve performance in distributed configuration. You can achieve generic performance tuning by changing the Memory, JVM, and Remote connection settings. Memory Settings There are different strategies in memory setting to improve performance. Server and Embedded Settings These settings are valid for both Server component and the JVM where the Java application is run using OrientDB in Embedded mode, by directly using plocal. The most important thing on tuning is assuring the memory settings are correct. What can make a real difference is the right balancing between the heap and the virtual memory used by Memory Mapping, especially on large datasets (GBs, TBs and more) where the inmemory cache structures count less than raw IO. For example, if you can assign maximum 8GB to the Java process, it”s usually better assigning small heap and large disk cache buffer (off-heap memory). Try the following command to increase the heap memory. java -Xmx800m -Dstorage.diskCache.bufferSize=7200 … The storage.diskCache.bufferSize setting (with old “local” storage it was file.mmap.maxMemory) is in MB and tells how much memory to use for Disk Cache component. By default it is 4GB. NOTE − If the sum of maximum heap and disk cache buffer is too high, it could cause the OS to swap with huge slowdown. JVM Settings JVM settings are encoded in server.sh (and server.bat) batch files. You can change them to tune the JVM according to your usage and hw/sw settings. Add the following line in server.bat file. -server -XX:+PerfDisableSharedMem This setting will disable writing debug information about the JVM. In case you need to profile the JVM, just remove this setting. Remote Connections There are many ways to improve performance when you access the database using a remote connection. Fetching Strategy When you work with a remote database you have to pay attention to the fetching strategy used. By default, OrientDB client loads only the record contained in the resultset. For example, if a query returns 100 elements, but if you cross these elements from the client, then OrientDB client lazily loads the elements with one more network call to the server for each missed record. Network Connection Pool Each client, by default, uses only one network connection to talk with the server. Multiple threads on the same client share the same network connection pool. When you have multiple threads, there could be a bottleneck since a lot of time is spent waiting for a free network connection. This is the reason why it is important to configure the network connection pool. The configuration is very simple, just 2 parameters − minPool − It is the initial size of the connection pool. The default value is configured as global parameters “client.channel.minPool”. maxPool − It is the maximum size the connection pool can reach. The default value is configured as global parameters “client.channel.maxPool”. If all the pool connections are busy, then the client thread will wait for the first free connection. Example command of configuration by using database properties. database = new ODatabaseDocumentTx(“remote:localhost/demo”); database.setProperty(“minPool”, 2); database.setProperty(“maxPool”, 5); database.open(“admin”, “admin”); Distributed Configuration Tuning There are many ways to improve performance on distributed configuration. Use Transactions Even when you update graphs, you should always work in transactions. OrientDB allows you to work outside of them. Common cases are read-only queries or massive and nonconcurrent operations can be restored in case of failure. When you run on distributed configuration, using transactions helps to reduce latency. This is because the distributed operation happens only at commit time. Distributing one big operation is much efficient than transferring small multiple operations, because of the latency. Replication vs Sharding OrientDB distributed configuration is set to full replication. Having multiple nodes with the same copy of database is important for scale reads. In fact, each server is independent on executing reads and queries. If you have 10 server nodes, the read throughput is 10x. With writes, it”s the opposite: having multiple nodes with full replication slows down the operations, if the replication is synchronous. In this case, sharding the database across multiple nodes allows you to scale up writes, because only a subset of nodes are involved on write. Furthermore, you could have a database bigger than one server node HD. Scale up on Writes If you have a slow network and you have a synchronous (default) replication, you could pay the cost of latency. In fact when OrientDB runs synchronously, it waits at least for the writeQuorum. This means that if the writeQuorum is 3, and you have 5 nodes, the coordinator server node (where the distributed operation is started) has to wait for the answer from at least 3 nodes in order to provide the answer to the client. In order to maintain the consistency, the writeQuorum should be set to the majority. If you have 5 nodes the majority is 3. With 4 nodes, it is still 3. Setting the writeQuorum to 3 instead of 4 or 5 allows to reduce the latency cost and still maintain the consistency. Asynchronous Replication To speed things up, you can set up Asynchronous Replication to remove the latency bottleneck. In this case, the coordinator server node executes the operation locally and gives the answer to the client. The entire replication will be in the background. In case the quorum is not reached, the changes will be rolled back transparently. Scale up on Reads If you already set the writeQuorum to the majority of nodes, you can leave the readQuorum to 1 (the default). This speeds up all the reads. Print Page

OrientDB – Upgrading ”; Previous Next While upgrading, you have to consider the version number and the format. There are three types of formats – MAJOR, MINOR, PATCH. MAJOR version entails incompatible API changes. MINOR version entails functionality in a backward-compatible manner. PTCH version entails backward-compatible bug fixes. To synchronize between minor and major versions, you may need to export and import the databases. Sometimes you many need to migrate the database from LOCAL to PLOCAL and need to migrate the graph to RidBag. Migrate from LOCAL Storage Engine to PLOCAL Starting from version 1.5.x OrientDB comes with a brand new storage engine: PLOCAL (Paginated LOCAL). It”s persistent like the LOCAL, but stores information in a different way. Following points show the comparison between PLOCAL and LOCAL − In PLOCAL Records are stored in cluster files, while with LOCAL was split between cluster and data-segments. PLOCAL is more durable than LOCAL because of the append-on-write mode. PLOCAL has minor contention locks on writes, which means more concurrency. PLOCAL doesn”t use Memory Mapping techniques (MMap) so the behavior is more “predictable”. To migrate your LOCAL storage to the new PLOCAL, you need to export and re-import the database using PLOCAL as storage engine. Following is the procedure. Step 1 − Open a new shell (Linux/Mac) or a Command Prompt (Windows). Step 2 − Export the database using the console. Follow the given command to export database demo into demo.json.gzip file. $ bin/console.sh (or bin/console.bat under Windows) orientdb> CONNECT DATABASE local:/temp/demo admin admin orientdb> EXPORT DATABASE /temp/demo.json.gzip orientdb> DISCONNECT Step 3 − On a local filesystem, create a new database using the “plocal” engine − orientdb> CREATE DATABASE plocal:/temp/newdb admin admin plocal graph Step 4 − Import the old database to the new one. orientdb> IMPORT DATABASE /temp/demo.json.gzip -preserveClusterIDs=true orientdb> QUIT If you access the database in the same JVM, remember to change the URL from “local:” to “plocal:” Migrate Graph to RidBag As of OrientDB 1.7, the RidBag is a default collection that manages adjacency relations in graphs. While the older database managed by an MVRB-Tree are fully compatible, you can update your database to the more recent format. You can upgrade your graph via console or using the ORidBagMigration class. Connect to database CONNECT plocal:databases/<graphdb-name> Run upgrade graph command Print Page Previous Next Advertisements ”;

OrientDB – Update Edge ”; Previous Next Update edge command is used to update edge records in the current database. This is equivalent to actual update command in addition to checking and maintaining graph consistency with vertices, in the event that you update the out and in properties. The following statement is the basic syntax of Update Edge Command. UPDATE EDGE <edge> [SET|INCREMENT|ADD|REMOVE|PUT <field-name> = <field-value> [,]*]|[CONTENT|MERGE <JSON>] [RETURN <returning> [<returning-expression>]] [WHERE <conditions>] [LOCK default|record] [LIMIT <max-records>] [TIMEOUT <timeout>] Following are the details about the options in the above syntax. <edge> − Defines the edge that you want to update. You can choose between Class that updates edges by class, Cluster that updates edges by cluster, using CLUSTER prefix, or Record ID that updating edges by record ID. SET − Updates the field to the given values. INCREMENT − Increments the given field by the value. ADD − Defines an item to add to a collection of fields. REMOVE − Defines an item to remove from a collection of fields. PUT − Defines an entry to put into map fields. RETURN − Defines the expression you want to return after running the update. WHERE − Defines the filter condition. LOCK − Defines how the record locks between the load and updates. LIMIT − Defines the maximum number of records. Example Let us consider an example of updating the edge named ‘address’ in the person class by taking data from the address table having area Id = 001, and the person name = Krishna. orientdb> UPDATE EDGE address SET out = (SELECT FROM Address WHERE areaID = 001) WHERE name = ”krishna” If the above query is executed successfully, you will get the following output. Updated edge ”[address[#10:3][#11:3->#14:2]]” in 0.012000 sec(s) Print Page Previous Next Advertisements ”;