Java Multi-Model API

(since v 3.0)

OrientDB was born as a Document database. The fact that it has physical links
(index-free adjacency) makes it a graph database, but still, the core API was
designed as a Document API; the Graph API was added later, as a separate component,
based on Apache TinkerPop 2.x standard.

This led to a big discrepancy between the two APIs. See these two examples:

Multi-Model Data Hierarchy

The picture below shows the interface hierarchy of the Multi-Model API

ORecord: this is a pre-existing interface, common to all the persistent records

Its main goal is to provide an abstraction to obtain low level information (eg. identity) and behavior
(eg. save and delete) for persistent entries

OBlob: represents BLOB (binary) records

OElement: represents plain documents (so also vertices and edges). It includes methods
to manipulate properties and to check if current element is a vertex or an edge.

Attention: until v 2.2 the Document API relied on ODocument class only. ODocument is still there as the main implementation of OElement, but please don't use it directly, always use OElement instead

OVertex: is the basic interface for vertices, it includes methods to manipulate and traverse connected edges and vertices

OEdge: is the basic interface for edges, it includes methods to retrieve info regarding connected vertices

Query Mechanisms and Interfaces

In v.2.2 you needed the orientdb-graphdb module to perform graph queries (eg. queries that use out()/in() operators);
in V 3.0 we moved all the basic graph operators to the core module, basically you don't need orientdb-graphdb anymore, unless
you need explicit support for Apache TinkerPop API.

V 3.0 also includes a new query interface that explicitly return elements that can be converted to the Multi-Model
interface hierarchy.