Hi Cyprien,
it's a bit hard (and long) for me to answer without a minimal dataset to
test, if you have a chance to provide one, I'll be happy to review the
queries
Thanks
Luigi
2017-10-30 19:04 GMT+01:00 Cyprien Gottstein <gottstein.cypr...@gmail.com>:
> Greetings,
>
> OrientDB : Version 2.2.28
>
> I am facing a problem using OSQL MATCH,
>
> Basically, we have a query language which we translate into OSQL to query
> our OrientDB database.
> We have to do graph pattern matching and the MATCH statement seems
> perfectly appropriate for our needs (and you have all my thanks for adding
> that to OrientDB ! Sincerely.), however... it does not work.
>
> So first of all, is this the right way to use a while condition into the
> MATCH statement ?
>
> MATCH
> {class:Projection, as:a} -as_ontology_class-> {as:b},
> {class:owl_class, as:c, where:(ori = "http://purl.org/vso/ns#Bicycle"; )}
> <-isA- {class:owl_class, as:b, while:(true)}
> RETURN a
>
>
>
> What bothers me is that *"a"* may be directly linked to *"c"*, and
> sometimes it must pass through *"b"* to reach *"c"* . It works most of
> the time but i'm never really sure about the global method, if this should
> not be split into two queries.
> Example:
>
> projection (vertex) : P1, P2
> owl_class (vertex) : bicycle, bus, busOrCoach
>
> isA (edge) : Bus -isA-> BusOrCoach
> as_ontology_class (edge) : P1 -as_ontology_class-> bicycle, P2
> -as_ontology_class-> Bus
>
> If i use the following query :
> MATCH
> {class:Projection, as:a} -as_ontology_class-> {as:b},
> {class:owl_class, as:c, where:(ori IN ["http://purl.org/vso/ns#Bicycle";, "
> http://purl.org/vso/ns#BusOrCoach";] )} <-isA- {class:owl_class, as:b,
> while:(true)}
> RETURN a
>
>
>
> both P1 and P2 will be returned, isn't that strange ? OSQL made the
> assumption for me to link directly a and c. It is good to me because that
> is what i want but i can't help but wonder because this is not what i
> expected.
> Next, take the following dataset:
>
> Person (vertex) : A, B, C, D
> Name (property) : A.name = Alice, B.name = Bob, C.name = Charlie, D.name =
> Daniel
>
>
> knows (edge) :
> A -knows-> B,
> A -knows-> C,
> B -knows-> C,
> B -knows-> D,
> C -knows-> A,
> C -knows-> B,
> D -knows-> B
>
> With the following query :
> MATCH
> {class:Person, as:a} -knows-> {class:Person, as:b} -knows-> {class:Person,
> as:c, where:(name NOT IN ["Daniel"] )}
> RETURN a ) )
>
>
>
> I get no person matching even though i see the pattern A -knows-> B -
> knows-> C with C.name NOT IN ["Daniel"].
> Now, if i add a fifth person at the farest location possible from Daniel:
>
> Person (vertex) : A, B, C, D, E
> Name (property) : A.name = Alice, B.name = Bob, C.name = Charlie, D.name =
> Daniel, E.name = Ted
>
>
> knows (edge) :
> A -knows-> B,
> A -knows-> C,
> B -knows-> C,
> B -knows-> D,
> C -knows-> A,
> C -knows-> B,
> E -knows-> C
>
> Same query :
> MATCH
> {class:Projection, as:a} -knows-> {class:Projection, as:b} -knows-> {class
> :Projection, as:c, where:(name NOT IN ["Daniel"] )}
> RETURN a ) )
>
>
>
> For the E vertex there is no Person called Daniel within a depth of two
> through the "knows" edge, still, the results are the same, no person
> matching.
> If i go back to the dataset without E and i change the "NOT IN" operator
> with "=" :
>
> MATCH
> {class:Person, as:a} -knows-> {class:Person, as:b} -knows-> {class:Person,
> as:c, where:(name != "Daniel" )}
> RETURN a ) )
>
>
>
> The query return A, B, C and D.
>
> Why does the use of a list have such impacts onto the query what am i
> missing ?
> If you take the very first query :
>
> MATCH
> {class:Projection, as:a} -as_ontology_class-> {as:b},
> {class:owl_class, as:c, where:(ori = "http://purl.org/vso/ns#Bicycle"; )}
> <-isA- {class:owl_class, as:b, while:(true)}
> RETURN a
>
>
>
> I have some cases where it fails or work depending the dataset with a
> runtime exception "Invalid pattern to match!" (line 668, version 2.2.28 in
> OMatchStatement)
> I do not know exactly if this has some impact on the execution but when i
> tried to execute in debug mode the query with pointbreaks into
> OMatchStatement i saw that the order of executionPlan.sortedEdges where
> inverted in the case of the query fails or succeed.
> executionPlan.sortedEdges in case of failure : [ { "out" : true, "edge" :
> "b->a" } , { "out" : false, "edge": "b->c" } ]
> executionPlan.sortedEdges in case of success : [ { "out" : true, "edge" :
> "b->c" } , { "out" : false, "edge" : "b->a" } ]
>
> I saw it was based on some estimated size of the roots entries so I tried
> to modify the dataset which fails to have the same sortedEdges ordering but
> i could not manage to change the order back, so no real clue on this. Also,
> after some tries i noticed that if i put a deliberately unsatisfiable
> clause on *"a" *the query will be executed properly:
>
> MATCH
> {class:Projection, as:a, where:(false = true)*} -as_ontology_class-> {as:b
> }, *this could be anything as long as i'm sure it will never be true.
> {class:owl_class, as:c, where:(ori = "http://purl.org/vso/ns#Bicycle"; )}
> <-isA- {class:owl_class, as:b, while:(true)}
> RETURN a
>
>
>
> I won't get any result back, but there won't be any errors.
>
> I am very sorry if it feels fuzzy, i will try to upload a dataset tomorrow,
>
> Thanks,
>
> Cyprien Gottstein.
>
>
>
>
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OrientDB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to orient-database+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
