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(); oDocEdges.iterator().next().getClass(); 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? On Tuesday, October 13, 2015 at 1:47:04 AM UTC+2, l.garulli wrote: > > 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 > OrientDB <http://orientdb.com/> > > > On 12 October 2015 at 15:58, Johan Sjöberg <[email protected] > <javascript:>> wrote: > >> 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.orientechnologies.orient.object.db.OCommandSQLPojoWrapper.execute >> (OCommandSQLPojoWrapper.java:57) >> >> 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. >> >> >> -- >> >> --- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
