Hello Luigi, I have done further research about the "Person Problem" and made some progress, i can finally make it work but... its strange. Take this request
> MATCH
> {class:Projection, as:a, where:(namespace = "IOT-Explorer")}
> -foaf_0_1_knows-> {class:Projection, as:b} -foaf_0_1_knows->
> {class:Projection, as:c, where:(ori NOT IN [
> "http://orange-labs.fr/fog/ont/iot.owl#Daniel" ])}
> RETURN a
>
it can also be expressed this way:
> MATCH
> {class:Projection, as:a, where:(namespace = "IOT-Explorer")}
> -foaf_0_1_knows-> {class:Projection, as:b} -foaf_0_1_knows->
> {class:Projection, as:c, where:*(NOT ( ori IN [
> "http://orange-labs.fr/fog/ont/iot.owl#Daniel" ] )*)}
> RETURN a
>
Both requests work on the dataset you can find in the attached files but
only the second one works onto my data. Unfortunately, i can't expose here
the true dataset, i don't have the right to do so.
I need to investigate, i'm starting to doubt the sanity of our database,
when i adjusted the extract by removing pretty much everything that was
unneeded, i also rebuilt manually the edges because we had a lot of
duplicata and i wanted things to be clean. Once i finished it suddenly
worked and even though we had duplicates, every edges where in the right
direction, the traversal/match of OrientDB should not have been mislead by
the duplicates.
I don't have the time right now, i must go, i will reconstruct the
minimized dataset, with keeping the duplicates, to see if this strange
behavior is still happening, it will be a bit messier but i will give it to
you.
The other problems about the invalid pattern to match is still ongoing
though.
I won't be there tomorrow, so hopefully i will be back with more
information in two days,
Thanks,
Cyprien.
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
demo-extract.gz
Description: Binary data
