Well, with either approach you're actually using the Graph API once you
start using the OrientGraph object.
A Vertex (OrientVertex) is built on top of a document, and its ODocument
can be obtained by calling vertex.getRecord().
But an ODocument is not a Vertex.
By working with OrientVertex obj
Actually the better approach for me is to stick with the document api and
do like so:
ODatabaseDocumentTx db = pool.acquire();
OrientGraph g = new OrientGraph(db);
Out of interest is the a way to cast ODocument to Vertex and vice versa?
PS Would be nice if you could provide a one liner in the
Hey Christian,
You can use the Document API via that call to getRawGraph() which returns
an ODatabaseDocumentTx object.
The Graph API, which implements the TinkerPop Blueprints interface, is also
very easy to use and makes it simpler to add edges to vertices.
Something to note about the Graph
Thanks for the quick response Colin
If I got you right, I can switch to the Graph API and use the Document API
functionality out of the Graph API right? Does this mean I can get
a ODatabaseDocumentTx via the Graph API also? This would be very great!
But anyway I can always use the sql interface
Hi Christian.
If you want OrientDB to manage your links between the vertices, then yes,
you'll need to use the Graph API to create edges and add them to the
vertices.
If you want to manage them yourself, then the Document API will work fine
by maintaining the links yourself.
Have you looked a