4 ms·

It's fantastic. One of the areas where it has improved by leaps and bounds is in the documentation of it's "sql" like query language. The tcp api and the http

It's fantastic. One of the areas where it has improved by leaps and bounds is in the documentation of it's "sql" like query language. The tcp api and the http api are well documented as well. And if you are learning to use orient db for the first time. The getting started guide, and the wiki on main concepts is great and you will get up to speed pretty quickly. There are 240 pages(!) in the wiki so it is pretty exhaustive in case you need to know about orient db more ddeply. Where I feel it lacks is in the documentation of client libraries. since orient db could be used both using http and the client libraries I was not sure which one would be the best choice. I had a good experience using the http api in couchdb and elastic search so my first instinct was to use that but I am still not sure if it is the right way? Any way I think the orient db documentation is fantastic but it could do with better organization and probably some tips from devs on how to use it best. If I ever need a graph database I am definitely using orient db. As a side note I think orient db's reputation of a graph database might be doing it more harm than good since it is really much more than that. It can save data as documents, build relationships on them and even do full text search. I think the orient db guys should focus efforts on marketing other aspects of orient db (like the awesome sql language) besides the graph part.

phpnode 12y ago
Regarding the choice between the REST API and the binary protocol - it depends :) If you're using a client library that supports the binary protocol it's probably worth using that because it exposes every feature of orient and it's the more efficient option. However, if you're writing a client library from scratch, you'll find the REST version a whole lot simpler to implement - the binary protocol has a few awkward edge cases. There are actually some hidden gotchas with both the binary and REST transports, but they are not show stoppers and they're being actively worked on. Disclaimer: I wrote a client library for node.js[0] and am in the process of writing one for php[1]. [0] https://github.com/codemix/oriento https://github.com/codemix/oriento [1] https://github.com/codemix/php-orientdb https://github.com/codemix/php-orientdb

phpnode 12y ago

Regarding the choice between the REST API and the binary protocol - it depends :) If you're using a client library that supports the binary protocol it's probably worth using that because it exposes every feature of orient and it's the more efficient option. However, if you're writing a client library from scratch, you'll find the REST version a whole lot simpler to implement - the binary protocol has a few awkward edge cases. There are actually some hidden gotchas with both the binary and REST transports, but they are not show stoppers and they're being actively worked on. Disclaimer: I wrote a client library for node.js[0] and am in the process of writing one for php[1]. [0] https://github.com/codemix/oriento https://github.com/codemix/oriento [1] https://github.com/codemix/php-orientdb https://github.com/codemix/php-orientdb