OrientDB doesn't split Documents between different classes (as many OR-Mapping tools do). Each Document will reside in the cluster of its most base class. When you execute a query against a class that has sub-classes, OrientDB will search into the clusters of the target class and all its sub-classes. To know more see How it works.
OrientDB needs to know the relationships between the class inheritance. Note that this is an abstract concept that applies to both POJOs and Documents.
Example:
OClass account = database.getMetadata().getSchema().createClass("Account");
OClass company = database.getMetadata().getSchema().createClass("Company")
.setSuperClass(account);
By default all the queries are polymorphics. Using the example above with this SQL query:
SELECT FROM account WHERE name = 'Google'
Will be returned all the instances of Account and Company classes that has the property name equals to "Google".
Consider this example. We have 3 classes, with the cluster-id between parenthesis:
Account(10) <|--- Company (13) <|--- OrientTechnologiesGroup (27)
OrientDB, by default, creates a separate cluster for each class.
This cluster is indicated by the "defaultClusterId" property in OClass class and indicates the cluster used by default when not specified. However the OClass has the property "clusterIds" (as int[]) that contains all the clusters able to host the records of that class.
By default "clusterIds" and "defaultClusterId" are the same.
When you execute a query against a class, OrientDB limits the result sets only to the records of the clusters contained in the "clusterIds" property.
In this way when you execute this:
SELECT FROM Account WHERE name.toUpperCase() = 'GOOGLE'
Will return all the records for "GOOGLE" contained in all the three classes because for the class "Account" OrientDB searches inside the clusters 10, 13 and 27 following the inheritance specified in the schema.