Closed zhlu9890 closed 5 years ago
I looked the 16 results from FILTER e.created <= @ts AND e.expired >= @ts
and those seems to be correct, however when using PRUNE e.created > @ts OR e.expired < @ts
the 16 results were not returned. Here is the query, could you try to see if I miss anything,
WITH GO_terms
FOR t in GO_terms
FILTER t.id == @id
FILTER t.created <= @ts AND t.expired >= @ts
limit 1
FOR v, e IN 1..100 OUTBOUND t GO_edges
PRUNE e.created > @ts OR e.expired < @ts
FILTER e.type == "is_a"
SORT v.id ASC
LIMIT @offset, @limit
RETURN {term: v, edge: e}
@zhlu9890 We still need to verify what are the actual correct results. If you go to http://geneontology.org/docs/download-ontology/, download the "go.obo" file, find the entry for your term ID, and see if you can trace what the correct results are for the query you are testing.
I downloaded the go.obo
file and traced GO:0000002
. Here is the my finding:
GO:0000002 is_a GO:0007005
GO:0007005 is_a GO:0006996
GO:0006996 is_a GO:0016043
GO:0016043 is_a GO:0009987
GO:0016043 is_a GO:0071840
GO:0009987 is_a GO:0008150
GO:0071840 is_a GO:0008150
So the 16 results from FILTER e.created <= @ts AND e.expired >= @ts
are correct, it had all the edges with some duplicates. I am still not sure why PRUNE e.created > @ts OR e.expired < @ts
is not working.
As I mentioned on slack, it looks like the query returns the correct results, and the data currently loaded in the GO_terms and GO_edges collections are incorrect. We can work with Gavin to get this sorted out. In the mean time, I will check to see if this PR is ready to merge.
Again as mentioned as slack, the query was actually not right, and we need to add a e != null
condition in the prune expression, as described here: https://github.com/arangodb/arangodb/issues/9290
@zhlu9890 Let me know when this PR is ready for a re-review and merge.
Updated queries and adopted Eric's FILTER to use path.edges[*].attribute ALL
instead of PRUNE
. The queries with depth 1 just use simple FILTER.
We are in business :100: :champagne:
And were you able to verify that these actually are the incorrect results agains the source data? What is the correct result?
On Mon, Sep 16, 2019 at 9:46 AM Zhenyuan Lu notifications@github.com wrote: