Labels and Classes conventions
wolf4ood opened this issue · comments
Hi Guys
i've started to work in the develop branch, i'm refactoring the code in order to use
the new MultiModel API that the Core of OrientDB will offer in 3.0. I've stumble upon the current
default labels convention
https://github.com/orientechnologies/orientdb-gremlin#labels-and-classes
I was able to make all the tests works with the new API, but i have to to configure this
CONFIG_LABEL_AS_CLASSNAME
to true
by default, since the new APIs does not work with this conventions.
Can we remove this convention ? i guess everything will blow up :)
We can remove that convention if there is a way to create vertices and edges that have the same name. Maybe that's possible with the new API, the old one didn't allow for that, they ended up in the same class.
i don't think that is possible with the new API. The problem is that using another convention over ODB convention will lead to incompatibility issue.
I've done this test, I've created a new database and executed this code
OrientGraphFactory factory = new OrientGraphFactory("remote:localhost/Gremlin");
OrientGraph noTx = factory.getNoTx();
Vertex vertex = noTx.addVertex("label", "Person", "name", "John");
Vertex vertex1 = noTx.addVertex("label", "Person", "name", "Frank");
vertex.addEdge("Friend", vertex1);
factory.close();
This will create the class vertex Person
and the class Edge E_Friend
and this is a simple select from V
If i use this dataset from the API java all works well.
But for example if i want to create an edge with SQL API i should do
create edge E_Friend from #11:0 to #12:0
since the edge class is E_Friend
but that will lead to this situation
and from JAVA API i should do
Iterator<Vertex> iterator = noTx.vertices(new ORecordId(11,0));
Iterator<Edge> friend = iterator.next().edges(Direction.OUT, "E_Friend","Friend");
In order to get the both relationship from #11:0
And also impact the delete from SQL
delete edge #23:0
that will lead to the situation where the RidBags in both vertices are not updated well due the
fact that the executor will not find #23:0 in fields out_E_Friend , in_E_Friend but it is stored in
fields out_Friend
, in_Friend