OResultSet to ODocument conversion

We just upgraded our OrientDB version from 2.2.16 to 3.0.29. The upgrade went fine.

In the new version, there are a number of deprecated functions which we attempted to replace in our code as indicated in the documentation and help files. However, this did not quite work. For example, the following function:

public List<ODocument> executeCommand(OCommandSQL cmd, Map<String, String> params) {

  return ((params == null) 
    ? conn.get().command(cmd).execute() 
    : conn.get().command(cmd).execute(params));


where “conn.getDB()” returns an ODatabaseDocument object (was ODatabaseeDocumentTx before).

The function “command()” is marked as deprecated and may be replaced with either one of the following 4 interfaces “command(String, Map)”, “command(String, Object)”, “execute(String, String, Map)” or “(execute(String, String, Object)”. In either cases, the return is a OResultSet which does not help since we need a list of ODocument objects. Managed to convert the OResultSet to a ODocument list by doing this:

List docs = new ArrayList();
ODatabaseDocument db = conn.get();
OResultSet res = db.query(command.getText(), parms);
while (res.hasNext()) {

OResult r = res.next();
ODocument doc = new ODocument(r.toElement().toStream());


return (docs);

Obvious problem is that ODocument(byte[]) is deprecated …

The question is: using the above example, how does one in 3.0.29 get a list of ODocument objects without the use of deprecated interfaces?

Found a work-around by replacing

ODocument doc = new Document(r.toElement().toStream())


ODocument doc = (ODocument)r.toElement();

Still would be interested whether or not there is an “easier” way to achieve this, maybe without the need to process the result set.

Hi @tok

One of the main purposes of this refactoring is to get rid of the dependency from ODocument as an actual class, and replace it with OElement, that is an interface and makes the management of types hierarchy much easier (see the multi-model API hierarchy https://orientdb.com/docs/3.0.x/java/Java-MultiModel-API.html#multi-model-data-hierarchy)

Anyway, as of now, in 90% of the cases (and in 99% of the practical situations), the implementation still relies on ODocument and its subclasses, so I’d say you can go with this approach

List<ODocument> result;
try(OResultSet rs = db.query(queryText)){
  result = rs.stream().map(x -> (ODocument) x.toElement()).collect(Collectors.toList());

Anyway, this way you’ll lose a lot of the advantages of v 3.0, in particular you will still have huge lists in memory instead of a streamed result-set, so strongly suggest you to consider a refactoring to use the new API as it is.



Hi Luigi,

Thanks for the quick response. We will look at the re-factoring option.