orientechnologies / blueprints Goto Github PK

Right now we support asynchronous calls when work with remote client. Another interesting feature would be having a new API call to retrieve the status of calls. Like:

clientA -> Server, req 0
clientA -> Server, req 1
clientA -> Server, req 2
clientA -> Server, req 3

After X seconds the clientA asks for the results of asynch calls:

clientA <- Server, [ req 0 = ok, req 1 = ok, req 2 = ok, req 3 = ok ]

We could also get back the version ID to update client's cache.

Using the latest 1.6.0-SNAPSHOT (20130830-0231), I get the following error when creating a database:

java.lang.IncompatibleClassChangeError: Found interface com.orientechnologies.orient.core.metadata.OMetadata, but class was expected
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.checkForGraphSchema(OrientBaseGraph.java:509)
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.openOrCreate(OrientBaseGraph.java:800)
com.tinkerpop.blueprints.impls.orient.OrientBaseGraph.(OrientBaseGraph.java:100)
com.tinkerpop.blueprints.impls.orient.OrientTransactionalGraph.(OrientTransactionalGraph.java:36)
com.tinkerpop.blueprints.impls.orient.OrientGraph.(OrientGraph.java:27)

I'm using orientdb-1.6.0-20131025.164813-147-distribution. When I run the distributed server the OrientBaseGraph.addVertex doesn't update the document id. So it'll be something like "tinkerpop#15:-3".

It looks like the issue is when calling graph.autoStartTransaction().

If I bypass addVertex and just create a new OrientVertex without properties and called save on it, it worked. If I did it with properties it didn't work. So I commented out the graph.autoStartTransaction(); in OrientElement.java setProperties method and it worked.

Moved from: orientechnologies/orientdb#1650

Version 1.5 (last release)
We have a vertex with a date field.

if I call this gremlin through rest:
g.V('@Class','myVertex').has('dateField', T.lte, new Date())
Orient returns:
System.Exception: DB Error:InternalServerError. Msg:com.orientechnologies.orient.core.sql.OCommandSQLParsingException: Error on parsing command at position #65: Invalid keyword 'AUG'
Command: select from V where @Class = 'myVertex' and dateField <= Fri Aug 30 17:19:39 CEST 2013 LIMIT 2147483647

If I change the query in:
g.V('@Class','myVertex').as('x').has('dateField', T.lte, new Date())
all works.

Although the blueprints API seems to work fine despite this bug, this causes frames to trigger a NullpointerException.

The following test case does not include frames but shows that the OMVRBTreeRIDSet is not left in a consistent state after that the transaction is completed:
https://gist.github.com/mdelem/6376602

Moved from: https://github.com/tinkerpop/blueprints/issues/423

When you want the edges between 2 vertices it returns all edges with the same label and not just the edge that connects to the other_vertex.

Ex.
If I have 3 vertices (v1, v2, v3) and I add relationships like this:
v1.addEdge('targets', v2)
v1.addEdge('targets', v3)

Then if I call v1.getEdges(v2, Direction::Out, 'targets') it will return edges for both v2 and v3.

It's part of the OrientDB Blueprints api. Specifically https://github.com/tinkerpop/blueprints/blob/master/blueprints-orient-graph/src/main/java/com/tinkerpop/blueprints/impls/orient/OrientVertex.java in the getEdges method. It doesn't pass in the destinationVId when the field value is a collection greater than 1.

Create an index on a class with the name of the index prepended with the class name.
Ex. "BaseModel.guid"

Then when you call getVertices("guid", "123....") without the class name it goes into an infinite loop.

It looks like getVertices in OrientBaseGraph actually prepends the class name if there isn't one("V") before searching (another issue).

It then calls:
idx = getContext(true).rawGraph.getMetadata() .getIndexManager().getIndex(indexName);
It doesn't find anything for "V.guid" index so calls the query.has(key, val).vertices

In there it checks for indices as well but uses: ((KeyIndexableGraph) graph).getIndexedKeys(elementClass);

This returns "guid" so it thinks there's an index on it and calls graph.getVertices("guid", "123...") again.
And the loop continues.

Not sure if indexed_keys should have the full name of the index on it or if there is a reason why it's just the name without the class.