ClassCastException when creating edge

Skip to first unread message

Johan Sjöberg

Oct 12, 2015, 9:58:13 AM10/12/15
to OrientDB
So we are trying to switch to an embedded plocal server but struggling with creating edges. We are using the Java Object API and use SQL to create edges. For example the following query:

String q = "CREATE EDGE " + EdgeName.class.getSimpleName() + " FROM " + from.getId() + " TO " + to.getId();

Is executed in the following way:

db.command(new OCommandSQL(q)).execute();
Since we changed to embedded, plocal mode this doesn't work anymore. It throws the following error:

java.lang.ClassCastException: com.tinkerpop.blueprints.impls.orient.OrientEdge cannot be cast to com.orientechnologies.orient.core.record.impl.ODocument
 at com

If I instead try:

db.getUnderlying().command(new OCommandSQL(q)).execute();

Everything works fine.

I understand why the second call works fine, we access the documentdb and do all queries against this one rather than Java Object API layer. 
What I don't understand is why the first one fails. Why is it using blueprints' OrientEdge class? That makes no sense at all.

Anyone has a solution for this? I would prefer to not having to change all my edge creating db.command() to db.getUnderlying().command().
Mainly because I still want the bindings to my Java classes to work automatically. 

Luca Garulli

Oct 12, 2015, 7:47:04 PM10/12/15
to OrientDB
Object API is not compatible with Graph API. Choose one of them, don't use both at the same time.

Best Regards,

Luca Garulli
Founder & CEO


You received this message because you are subscribed to the Google Groups "OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit

Johan Sjöberg

Oct 13, 2015, 5:53:07 AM10/13/15
to OrientDB
I actually think this is a bigger problem than the Object API not being compatible with the Graph API. I think it is more the issue of the Document API not being compatible with the Graph API, which it should.
To my understanding, the object API simply uses the document API to map classes. By using SQL we return a document that is then mapped to a class. That is, doing the following is fine since I'm not really
using the graph API but rather the document mapping.

String q = "SELECT FROM EdgeName"
List<EdgeName> edges = db.command(new OCommandSQL(q)).execute();

Now consider the following:
String qe = "CREATE EDGE " + EdgeName.class.getSimpleName() + " FROM " + from.getId() + " TO " + to.getId();
List<EdgeName> edges = db.command(new OCommandSQL(q)).execute();

As stated, this doesn't work. It fails inside the db.command() when it tries to cast an OrientEdge to an ODocument. 
I don't think it is due to the ObjectAPI, in fact this indicates a bigger problem.
Since the Graph API is built on top of the ODocument API this should, imo, be possible:

String qe = "CREATE EDGE " + EdgeName.class.getSimpleName() + " FROM " + from.getId() + " TO " + to.getId();
List<ODocument> oDocEdges = db.getUnderlying().command(new OCommandSQL(qe)).execute();

But it now get a class cast exception on the last line. That is, even if explicitly use the document API it still returns an OrientEdge.

That surely can not be the expected behavior since we can return an edge just fine?
In fact, I think if that problem is fixed we won't have any issues with the original question either. 

Or am I completely wrong here?

Johan Sjöberg

Oct 13, 2015, 5:57:01 AM10/13/15
to OrientDB
Oh, and also, it works fine with a remote connection but not with a plocal connection. The behavior shouldn't differ right? Which is another reason indicating a bug.
Reply all
Reply to author
0 new messages