XPath-like queries in OrientDB

[Leo Romanoff]

Hi,

I'm very new to OrientDB and would like to ask a few questions.
Some of my questions refer to MongoDB, as I have some previous experience with it.

1) Does OrientDB support something like XPath for querying JSON documents?
    E.g. something like this proposal for MongoDB: https://jira.mongodb.org/browse/SERVER-736?
    I'm very interested in querying e.g. all documents that contain a certain key/field somewhere, but it is not known at which depth.

2) Does OrientDB index JSON documents somehow to speedup queries? How it does it? How many levels of JSON documents can be indexed?

3) Does OrientDB support something like XPath for querying graphs?

4) Compared to MongoDB, what are the pros and cons of OrientDB when working with JSON documents?

Thanks,
  Leo

[Luca Garulli]

On 19 April 2012 11:15, Leo Romanoff <romi...@gmail.com> wrote:

Hi,
I'm very new to OrientDB and would like to ask a few questions.
Some of my questions refer to MongoDB, as I have some previous experience with it.

1) Does OrientDB support something like XPath for querying JSON documents?
    E.g. something like this proposal for MongoDB: https://jira.mongodb.org/browse/SERVER-736?
    I'm very interested in querying e.g. all documents that contain a certain key/field somewhere, but it is not known at which depth.

Hi,

course! This is a graphdb afterall :-)

You can use the DOT (.) to traverse links or embedded documents. Example:

select from customer where address.city.country.name = 'Italy'

or in a graph of unknown size and deep the TRAVERSE operator helps:

select from ( traverse * from customer ) where name = 'Austria'

 

2) Does OrientDB index JSON documents somehow to speedup queries? How it does it? How many levels of JSON documents can be indexed?

 

OrientDB has indexing. You mean embedded/nested records?

3) Does OrientDB support something like XPath for querying graphs?

 

Exactly, but use the dot, not (.) the slash (/)

4) Compared to MongoDB, what are the pros and cons of OrientDB when working with JSON documents?

 

If you take JSON documents separated and connected there OrientDB is much faster because relationships are super optimized. Other benefits in comparison to MongoDB are the security, SQL and transactions.

Thanks,
  Leo

Lvc@

[Leo Romanoff]

Hi,

Thanks a lot for your reply!

On Friday, April 20, 2012 3:38:44 PM UTC+2, Lvc@ wrote:

    E.g. something like this proposal for MongoDB: https://jira.mongodb.org/browse/SERVER-736?
    I'm very interested in querying e.g. all documents that contain a certain key/field somewhere, but it is not known at which depth.

1) Does OrientDB support something like XPath for querying JSON documents?

Hi,

course! This is a graphdb afterall :-)

You can use the DOT (.) to traverse links or embedded documents. Example:

select from customer where address.city.country.name = 'Italy'

 

OK.
 

or in a graph of unknown size and deep the TRAVERSE operator helps:

select from ( traverse * from customer ) where name = 'Austria'

Aha! The traverse trick is very cool. Didn't know about it.
 

 

2) Does OrientDB index JSON documents somehow to speedup queries? How it does it? How many levels of JSON documents can be indexed?

 

OrientDB has indexing. You mean embedded/nested records?

Yes. Sure it has indexing. And indeed, I meant embedded/nested complex JSON documents, which have several levels of nesting.

I understand that OrientDB can traverse them (the trick above), but how are they indexed? Do I need to add index manually by means of special command? Is it done automatically? If the nesting depth is not known in advance, can I still index something independent of the nesting level, e.g. based on a field name? Or can I only create indices for a few top-most levels?

 

 

3) Does OrientDB support something like XPath for querying graphs?

 

Exactly, but use the dot, not (.) the slash (/)

Very nice.

 

4) Compared to MongoDB, what are the pros and cons of OrientDB when working with JSON documents?

 

If you take JSON documents separated and connected there OrientDB is much faster because relationships are super optimized. Other benefits in comparison to MongoDB are the security, SQL and transactions.

Yes. Transactions are cool and a big advantage. But I have a few more questions:

1) Are server-side operations similar to MongoDB "inc"/"dec" are supported? (see e.g. http://www.mongodb.org/display/DOCS/Updating#Updating-%24inc). The benefit of those is that you don't need to do the usual read/change/update, which saves a lot of time and avoids consistency problems and conflicting changes

2) Regarding transactions: I seem to remember that I read somewhere in the OrientDB docs that there can be at most one concurrent transaction for one cluster or one DB, or something like this. Unfortunately, I cannot find this place anymore. Is it just a misunderstanding on my side or there is indeed some sort of a limitation when using transactions?

Thanks,
  Leo

[Luca Garulli]

On 20 April 2012 16:21, Leo Romanoff <romi...@gmail.com> wrote:

Hi,
Thanks a lot for your reply!

...

Aha! The traverse trick is very cool. Didn't know about it.

Traverse is very powerful specially in conjunction with select statement.

 

I understand that OrientDB can traverse them (the trick above), but how are they indexed? Do I need to add index manually by means of special command? Is it done automatically? If the nesting depth is not known in advance, can I still index something independent of the nesting level, e.g. based on a field name? Or can I only create indices for a few top-most levels?

If you never use nested records creating a graph of documents, indexing it's very simple. Open the console and type:

> CREATE INDEX User.id UNIQUE

Indexes have a cost, so index only fields involved in queries. For more information: http://code.google.com/p/orient/wiki/Indexes#Create_an_index.

 

Yes. Transactions are cool and a big advantage. But I have a few more questions:

1) Are server-side operations similar to MongoDB "inc"/"dec" are supported? (see e.g. http://www.mongodb.org/display/DOCS/Updating#Updating-%24inc). The benefit of those is that you don't need to do the usual read/change/update, which saves a lot of time and avoids consistency problems and conflicting changes

 

This is a new entry in SVN trunk not yet documented. Use it as:

update account increment salary = 10 where salary < 1000

2) Regarding transactions: I seem to remember that I read somewhere in the OrientDB docs that there can be at most one concurrent transaction for one cluster or one DB, or something like this. Unfortunately, I cannot find this place anymore. Is it just a misunderstanding on my side or there is indeed some sort of a limitation when using transactions?

Lvc@

 

Thanks,
  Leo