Labels and Classes conventions

[wolf4ood]

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 :)

[mpollmeier]

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.

[wolf4ood]

@mpollmeier

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