:) ↠happy dev
After 1 hour playing with it, I'm all excited. Their "Studio" seems to be exactly what I was needing: it uses a kind of modest SQL superset to manipulate the graph. It has schemas, ...and probably anything I could possibly ask for. Awesome. Ok it's just an hour, but I had to share it! I'll keep sharing my feelings as I get deeper in the beast.
Yeah, no I don't need big performance indeed.
Here is a taste:
MATCH
{Class: Profiles, where: (Name='Santo')}
<-HasProfile-
{Class: Customers}
-HasVisited->
{Class: Locations}
RETURN $pathelements
https://orientdb.org/docs/3.0.x/sql/SQL-Commands.html (https://orientdb.org/docs/3.0.x/sql/SQL-Commands.html)
And Live Queries (https://orientdb.org/docs/3.0.x/java/Live-Query.html).
There's a nice idea that comes to mind: in OpenCog, they can store queries in the Atomspace (https://wiki.opencog.org/w/AtomSpace):
Queries from the query language are graphs themselves. So queries can be stored in the Atomsapce. This is very unlike SQL, where you cannot store a query in the database itself. I think this is also very unlike every other graph DB (not sure). In particular, this allows you to perform reverse-queries: given an answer, find all the questions which it answers. Note that all chat-bots are in fact custom-purpose reverse-query databases (consider the I * you -> I * you too rewrite rule from AIML). The AtomSpace generalizes this.
It's possible to do something similar in OrientDB, storing in the db a graph of a MATCH query like:
MATCH {Class: Profiles}<-HasProfile-{Class: Customers}-HasVisited->{Class: Theatres}