Aha! Interesting that the bracket syntax is 4X faster than using the WHERE
clause. That's a bit surprising, as I would have thought that the query
optimizer would have arrived at the same execution plan for either syntax,
since they are functionally the same.
Anyone from Orient care to comment
Hi Eric,
at this stage the query executor is not smart enough to understand that the
two syntaxes have the same meaning, it just executes some of the
elaboration steps (eg. square bracket filtering) the way they are declared.
There are very important plans about this in the roadmap. In 2.1 we
@Luigi: Excellent. Thanks for the quick and detailed response!
--Eric
On Wed, Jul 22, 2015 at 8:21 AM, Luigi Dell'Aquila
luigi.dellaqu...@gmail.com wrote:
Hi Eric,
at this stage the query executor is not smart enough to understand that
the two syntaxes have the same meaning, it just
Hi,
at this link http://orientdb.com/orientdb-improved-sql-filtering/
I have founded Squared brackets [] allow to:
- filtering by one index, example out()[0]
- filtering by multiple indexes, example out()[0,2,4]
- filtering by ranges, example out()[0-9]
- filtering by equal conditions (only
Interesting. I wonder if the bracket syntax is even supposed to work or
if it only works with = ? Although that would seem pretty strange. I
suppose putting all of it in the WHERE clause would work fine, too, and
once the query is parsed, should produce an identical execution plan.
--Eric
On
Hi Eric,
the query SELECT
expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour=10
and hour=20].out('haveLogs')) FROM Year WHERE year = 2012
should work.
Alessandro
--
---
You received this message because you are subscribed to the Google Groups
OrientDB group.
To
Hi,
I'm using version 2.0.12 and I have problem with in the code [hour=10
and hour=20]
I solved the problem with the following query:
select expand(out('haveLog')) from (SELECT
expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour'))
FROM Year WHERE year = 2012) where hour=10
Hi Eric,
the query would be something like :
SELECT
expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour=10].out('haveLogs'))
FROM Year WHERE year = 2012
Regards,
Alessandro
--
---
You received this message because you are subscribed to the Google Groups
OrientDB
@Alessandro: Ah, very nice! To me, this syntax actually makes more sense.
:) But regardless, it also seems more flexible. For example, I think this
should be possible, right?
SELECT
expand(out('haveMonth')[month=3].out('haveDay')[day=20].out('haveHour')[hour=10
and hour=20].out('haveLogs')) FROM
On Saturday, July 18, 2015 at 7:39:56 PM UTC+2, Eric24 wrote:
why the links between the various date parts was done using a LINKMAP
instead of edges? To my way of thinking, using edges would be more graph
like, where as LINKMAP is more document like. What are the pros/cons?
For one
Yes, that makes sense (that's a very interesting query syntax; I understand
what it does, but I'm not 100% clear on how it works). What would an
equivalent query look like if this has been implemented using edges?
On Sunday, July 19, 2015 at 4:47:47 AM UTC-5, hartmut bischoff wrote:
On
11 matches
Mail list logo
