imbajin commented on code in PR #503:
URL: https://github.com/apache/hugegraph-doc/pull/503#discussion_r4130708054
##########
content/en/docs/clients/restful-api/edge.md:
##########
@@ -416,12 +416,21 @@ It is not possible to delete an attribute that is not set
as nullable.
- vertex_id: Vertex ID
- direction: Edge direction (OUT | IN | BOTH), default is BOTH
- label: Edge label
-- properties: Key-value pairs of properties (requires pre-built indexes for
property queries)
+- properties: Key-value pairs of properties (see index coverage below)
- keep_start_p: Default is false. When set to true, the range matching input
expression will not be automatically escaped. For example,
`properties={"age":"P.gt(0.8)"}` will be interpreted as an exact match, i.e.,
the age property is equal to "P.gt(0.8)"
- offset: Offset, default is 0
- limit: Number of queries, default is 100
- page: Page number
+Without `vertex_id`, a `properties` query searches edges globally. The
specified `label` needs a property index compatible with the query
+conditions. If `label` is omitted, every edge label that declares all queried
properties needs compatible index coverage, even if that label
Review Comment:
🧹 Blocking: no. Summary: A parent edge label with no direct edges does not
need a separate index when each data-bearing sub-label has a compatible index.
Evidence: `GraphIndexTransaction.checkIndexCoverage()` at apache/hugegraph#3243
head 0de33ed skips father labels, and `SourceIndexCoverageTest` confirms a
global query succeeds with compatible indexes on both sub-labels after removing
the parent index. Please clarify that the coverage rule excludes base labels
with no direct edges and that a parent index can cover sub-labels; otherwise,
compatible indexes on each data-bearing sub-label are sufficient.
##########
content/en/docs/clients/restful-api/vertex.md:
##########
@@ -367,14 +367,23 @@ PUT
http://127.0.0.1:8080/graphspaces/DEFAULT/graphs/hugegraph/graph/vertices/"1
#### Params
- label: Vertex type
-- properties: Property key-value pairs (precondition: indexes are created for
property queries)
+- properties: Property key-value pairs (see index coverage below)
- keep_start_p: Default is false. When set to true, the range matching input
expression will not be automatically escaped. For example,
`properties={"age":"P.gt(18)"}` will be interpreted as an exact match, i.e.,
the age property is equal to the string "P.gt(18)"
- offset: Offset, default is 0
- limit: Maximum number of results, default is 100
- page: Page number
All of the above parameters are optional. `page` can not be combined with a
non-zero `offset`, everything else can be combined in any way.
+If `label` selects a vertex label with the `PRIMARY_KEY` ID strategy and
`properties` supplies exact values for all its primary-key fields,
+the query looks up the vertex by ID. Additional property conditions are
checked on that vertex and do not need a property index.
+
+For other `properties` queries, the specified `label` needs a property index
compatible with the query conditions. If `label` is omitted,
+every vertex label that declares all queried properties needs a compatible
index, even if that label currently has no vertices. A label index
+alone does not index the properties. No compatible index produces an index
error; partial coverage also produces an index error instead of
Review Comment:
🧹 Blocking: no. Summary: Partial coverage does not always produce an index
error when a query value has the wrong property type. Evidence: At
apache/hugegraph#3243 head 0de33ed, `collectMatchedIndexes(..., true)` calls
`checkIndexCoverage` only when `validQueryConditionValues(...)` returns true;
`SourceIndexCoverageTest.testInvalidValuePrecedesPartialCoverageError` confirms
an invalid value returns an empty result. Please qualify this guarantee for
type-valid query values and mirror the clarification across the English and
Chinese vertex and edge pages.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
