Hi Szczepan,
The idea of our new graph module is to group a set of collections into one graph to be directly accessible in AQL or other interfaces in one bulk.
In order to do this a graph consists of a set of Edge Collections and a set of Vertex Collections where Edge Collections have one additional information --we called it relation -- they store the set of collections where edges are allowed to start and store the set of collections where the edges are allowed to end.
As one example:
isCustomer: [shop] -> [customer]
Also the new graph module allows to modify the set of collections at runtime, the idea is to add additional collections or to withdraw used ones.
Giving you the opportunity to seamlessly modify your graph during the development of your app:
You can start with an empty graph:
var g = graph_module._create("myGraph");
And on the fly add collections to it:
g._addVertexCollection("myVertexCollection")
Now your graph will only have a vertex collection and no edge collections.
In this case we call "myVertexCollection" an orphan collection as it has no options to be connected in this graph.
Later in the process you can add it to a relation:
graph._extendEdgeDefinitions(graph_module._undirectedRelation("myRelation", ["myVertexCollection"]))
Moving myVertexCollection out of the orphan state.
and also if you delete a relation again:
graph._deleteEdgeDefinition("myRelation");
this will remove the relation but will keep the collection in the graph (and move it to orphan state if it is not used in another relation)
So in this case you defined to remove "myRelation" but not "myVertexCollection" and we think it would be surprising if "myVertexCollection" is no longer in your graph.
That's why we created the concept of orphan collections.
However the information if a collection is an orphan or not should in most cases just be internal information, they behave exactly the same as "connected" vertex collections, but help for performance on our side.
best
Michael