Migration from 1.7.x to 2.0.x

Databases created with release 1.7.x are compatible with 2.0, so you don't have to export/import the database like in the previous releases. However, to use the new binary protocol you have to export and reimport the database into a new one. This will boost up your database performance of about +20% against old database.

Use the new binary serialization

To export and reimport your database follow these steps:

1) Stop any OrientDB server running

2) Open a new shell (Linux/Mac) or a Command Prompt (Windows)

2) Export the database using the console. Move into the directory where you've installed OrientDB 2.0 and execute the following commands:

> cd bin
> ./console.sh (or bin/console.bat under Windows)
orientdb> connect plocal:/temp/mydb admin admin
orientdb> export database /temp/mydb.json.gz
orientdb> disconnect
orientdb> create database plocal:/temp/newdb
orientdb> import database /temp/mydb.json.gz

Now your new database is: /temp/newdb.

API changes

Level2 Cache

We completely removed Level2 cache. Now only Level1 and Storage DiskCache are used. This change should be transparent with code that run on previous versions, unless you enable/disable Level2 cache in your code.

Changes

No more LOCAL engine

We completely drop the long deprecated LOCAL Storage. If your database was created using "LOCAL:" then you have to export it with the version you was using, then import it in a fresh new database created with OrientDB 2.0.

Server

First run ask for root password

At first run, OrientDB asks for the root's password. Leave it blank to auto generate it (like with 1.7.x). This is the message:

+----------------------------------------------------+
|          WARNING: FIRST RUN CONFIGURATION          |
+----------------------------------------------------+
| This is the first time the server is running.      |
| Please type a password of your choice for the      |
| 'root' user or leave it blank to auto-generate it. |
+----------------------------------------------------+

Root password [BLANK=auto generate it]: _

If you set the system setting or environment variable ORIENTDB_ROOT_PASSWORD, then its value will be taken as root password. If it's defined, but empty, a password will be automatically generated.

Distributed

First run ask for node name

At first run as distributed, OrientDB asks for the node name. Leave it blank to auto generate it (like with 1.7.x). This is the message:

+----------------------------------------------------+
|    WARNING: FIRST DISTRIBUTED RUN CONFIGURATION    |
+----------------------------------------------------+
| This is the first time that the server is running  |
| as distributed. Please type the name you want      |
| to assign to the current server node.              |
+----------------------------------------------------+

Node name [BLANK=auto generate it]: _

If you set the system setting or environment variable ORIENTDB_NODE_NAME, then its value will be taken as node name. If it's defined, but empty, a name will be automatically generated.

Multi-Master replication

With OrientDB 2.0 each record cluster selects assigns the first server node in the servers list node as master for insertion only. In 99% of the cases you insert per class, not per cluster. When you work per class, OrientDB auto-select the cluster where the local node is the master. In this way we completely avoid conflicts (like in 1.7.x).

Example of configuration with 2 nodes replicated (no sharding):

INSERT INTO Customer (name, surname) VALUES ('Jay', 'Miner')

If you execute this command against a node1, OrientDB will assign the cluster-id where node1 is master, i.e. #13:232. With node2 would be different: it couldn't never be #13.

Asynchronous replication

OrientDB 2.0 supports configurable execution mode through the new variable executionMode. It can be:

• undefined, the default, means synchronous
• synchronous, to work in synchronous mode
• asynchronous, to work in asynchronous mode

{
    "autoDeploy": true,
    "hotAlignment": false,
    "executionMode": "undefined",
    "readQuorum": 1,
    "writeQuorum": 2,
    "failureAvailableNodesLessQuorum": false,
    "readYourWrites": true,
    "clusters": {
        "internal": {
        },
        "index": {
        },
        "*": {
            "servers" : [ "<NEW_NODE>" ]
        }
    }
}

Set to "asynchronous" to speed up the distributed replication.

Graph API

OrientDB 2.0 disabled the auto scale of edge. In 1.7.x, if a vertex had 1 edge only, a LINK was used. As soon as a new edge is added the LINK is auto scaled to a LINKSET to host 2 edges. If you want this setting back you have to call these two methods on graph instance (or OrientGraphFactory before to get a Graph instance):

graph.setAutoScaleEdgeType(true);
graph.setEdgeContainerEmbedded2TreeThreshold(40);