Upgrading


OrientDB uses the Semantic Versioning System (http://semver.org), where the version numbers follow this format MAJOR.MINOR.PATCH, Here are the meanings of the increments:

  • MAJOR version entails incompatible API changes,
  • MINOR version entails functionality in a backward-compatible manner
  • PATCH version entails backward-compatible bug fixes.

So between PATCH versions, the compatibility is assured (example 1.7.0 -> 1.7.8). Between MINOR and MAJOR versions, you may need to export and re-import the database. To find out if your upgrade must be done over exporting and importing the database, see below in the column “Database”:

Compatibility Matrix

FROM TO Guide Blueprints Database Binary Protocol HTTP Protocol
2.0.x 2.1.x Release 2.1.x Final v2.6.0 Automatic 30 10
1.7.x 2.0.x Migration-from-1.7.x-to-2.0.x Final v2.6.0 Automatic 25 10
1.6.x 1.7.x Migration-from-1.6.x-to-1.7.x Final v2.5.0 Automatic 20, 21 10
1.5.x 1.6.x Migration-from-1.5.x-to-1.6.x Changed v2.5.x Automatic 18, 19 10
1.4.x 1.5.x Migration-from-1.4.x-to-1.5.x Changed v2.4.x Automatic 16, 17 10
1.3.x 1.4.x Migration-from-1.3.x-to-1.4.x Changed v2.3.x Automatic 14, 15 n.a.
1.2.x 1.3.x n.a. Changed v2.2.x OK OK OK Need export & Re-import 12, 13 n.a.

References:

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. Below are the main differences with LOCAL:

  • records are stored in cluster files, while with LOCAL was split between cluster and data-segments
  • more durable than LOCAL because the append-on-write mode
  • minor contention locks on writes: this means more concurrency
  • it 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 reimport the database using PLOCAL as storage engine. Follow the steps below:

1) open a new shell (Linux/Mac) or a Command Prompt (Windows)

2) export the database using the console. Example by exporting the database under /temp/db:

  1. $ bin/console.sh (or bin/console.bat under Windows)
  2. orientdb> CONNECT DATABASE local:/temp/db admin admin
  3. orientdb> EXPORT DATABASE /temp/db.json.gzip
  4. orientdb> DISCONNECT

3) now always in the console create a new database using the “plocal” engine:

a) on a local filesystem:

  1. orientdb> CREATE DATABASE plocal:/temp/newdb admin admin plocal graph

b) on a remote server (use the server’s credentials to access):

  1. orientdb> CREATE DATABASE remote:localhost/newdb root password plocal graph

4) now always in the console import the old database in the new one:

  1. orientdb> IMPORT DATABASE /temp/db.json.gzip -preserveClusterIDs=true
  2. orientdb> QUIT

5) If you access to 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 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

Using console

  • Connect to database CONNECT plocal:databases/GratefulDeadConcerts
  • Run upgrade graph command

Using the API

  • Create OGraphMigration instance. Pass database connection to constructor.
  • Invoke method execute()