[Improve]: support negative-label property queries with complete index coverage
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by tracing the index-planning path affected by PR #2994 and review the related context in #2992. Reproduce the negative-label query examples with indexed and unindexed labels, then add coverage for neq, NOT_IN, multi-label cases, and paging or limits. Done means no eligible label is skipped and incomplete coverage never produces a partial result.
Written by the indexing model from the issue text.
Description
Feature Description (功能描述)
Background
PR #2994 keeps queries that combine a negative label predicate with user-property
filters on the conservative no-index path. This prevents an index plan from
returning only the subset of labels that happen to have a compatible index.
Problem
Consider:
g.V().has(T.label, P.neq("author")).has("city", "Beijing")
The labels that can satisfy this query may include person, fan, and
follower. If only person has a city index, selecting that index returns
matching person vertices while silently omitting matching fan and
follower vertices.
An available partial index must never be used when it cannot produce a complete
candidate set.
Goal
Safely support negative-label predicates combined with property filters while
preserving complete query results.
Requirements
- Determine all schema labels that can satisfy the negative-label predicate and
- expose the queried property.
- Select an index plan only when every eligible label has compatible index
- coverage.
- When coverage is incomplete, either reject with
NoIndexExceptionor use an - explicitly bounded complete-scan plan.
- Never return a partial indexed subset as the query result.
- Preserve the current behavior of pure label predicates, for example:
g.V().has(T.label, P.neq("author")).- Cover
neq,NOT_IN/ equivalent flattened predicates, and multi-label - cases where only some labels are indexed.
- Add tests that verify no eligible label is skipped and that paging/limit are
- applied only after a complete candidate set is established.
Related
#2992
PR #2994
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 637
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 23
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/hugegraph
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
All issues in apache/hugegraph
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 90/100
apache/cloudstack#14222 ·
-
[BUG]茶杯方块在取茶时会引发崩溃 Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
1.0.0-alpha2 Type/Improvement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
wso2/dpdp-accelerator#272 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
area/frontend
Difficulty 2/5 1-3 hours Newbie friendliness 65/100