@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 e
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 rewr
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,
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 equ
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,
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>
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
@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
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
"OrientD
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
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?
>
>
Fo
11 matches
Mail list logo
