

OrientDB 1.7 is out - SanderMak
http://www.orientechnologies.com/orientdb-1-7-is-out/

======
weitzj
The last time I tried OrientDB was about 2 years ago. I really liked the idea
of an all Java DB. But somehow I could not get it work the way I wanted and
struggled with the lazy/eager loading.

I guess now is a good time to try it again and see how it goes.

------
evv
I've been a fan of orient for a while, although I have never actually used it.
IMHO, graph features are pretty critical for a document store to be very
useful. With full text search and extensible schemas, Orient has a very unique
and kick-ass design.

As much as I know about it, I have never actually used it. I want to play with
it, but I don't want to bother with all of the necessary sysadmin.

Does anybody offer OrientDB as a service?

~~~
phpnode
Orient themselves used to offer a hosted service, but they shut it down. IMHO
there are some things that need to be ironed out before a hosted version is
really viable.

In terms of sysadmin, it works pretty well out of the box for all but the
hugest of datasets and busiest sites, and the configuration is well
documented. It's no more difficult to set up than mysql for instance.

------
filearts
I notice that a Lucene-powered index is now included. I can see from the git
repo's wiki how to structure a query, but what seems to be missing is how to
return, or sort using, relevance information.

Can you chime in on how that works?

------
reactor
Is the documentation any better now? It was confusing when I tried to use
before.

~~~
brickcap
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
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)

------
mwexler
For those wondering, this is a variant on the MongoDB document database
approach... [http://www.orientechnologies.com/orientdb-vs-
mongodb/](http://www.orientechnologies.com/orientdb-vs-mongodb/)

~~~
phpnode
It's not really fair to call it a variant of Mongo's approach, OrientDB is an
SQL powered, NoSQL document-graph database which can model relationships
without requiring joins. It's quite different from Mongo in many ways.

Arguably OrientDB is the only data store on the market which actually matches
the web's data model - Documents + Links.

~~~
porker
So does that make it similar to Neo4j? Or is this more of a hybrid document
database with graph capabilities?

~~~
phpnode
it's also quite different from Neo4j which is a graph only database and is
poor at representing normal documents. Neo4j is also very expensive if you
want to use it in a cluster, whereas OrientDB imposes no such restrictions.

Orient is definitely a hybrid - it was a document database before it became a
document-graph database, but I believe it can still do everything that n4j
can. One of the nicest things about it is that it is object oriented - you can
define classes and then extend them, something you cannot do in mongo or any
RDBMS that I know of. This makes it very simple to use, because the database
structure can accurately reflect your application class structure, without any
need for leaky abstractions such as ActiveRecord.

~~~
dkersten
I'd say its a document database with direct links between documents, which can
be quickly and easily traversed like a graph database.

The graph API that OrientDB exposes (the TinkerPop api, basically) seems to be
built almost as a convention of which links should exist, on top of the
document database.

OrientDB is very flexible and powerful because of this: representing your data
as linked documents feels really natural.

I've been using RethinkDB lately, and I love it, but having used OrientDB
previously, I find the lack of direct links between documents makes for
complex and awkward nested queries. I'll continue to happily use RethinkDB,
but I'm also eagerly watching OrientDB's progress and expect I'll be using it
some more soon.

