imbajin commented on code in PR #503: URL: https://github.com/apache/hugegraph-doc/pull/503#discussion_r4323411638
########## content/en/docs/clients/restful-api/vertex.md: ########## @@ -367,14 +367,34 @@ 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 (`P.eq` and +`P.within` count as exact values), the query looks up the vertex by ID and checks additional property conditions on that vertex without a property index. +If all primary-key fields have conditions but any of them is not an exact value (`P.neq`, `P.gt`, `P.between`, `P.textcontains` and similar), the query is +rejected before property-index lookup, even if a matching property index exists. + +For other `properties` queries, the specified `label` needs a property index compatible with the query conditions. If `label` is omitted, candidate labels are +query-visible vertex labels that declare all queried properties, including labels that currently have no vertices. Labels hidden from normal query results, +including those being deleted, do not require coverage. If the specified `label` (provided it declares all queried non-OLAP properties), or every candidate +label, is hidden or being deleted, the query returns an empty result instead of an index error. A label index alone does not index properties. Review Comment: ⚠️ Important: The docs define candidates after filtering to query-visible labels, then say every candidate being hidden or deleting returns an empty result. In the server, that empty path requires at least one schema label to otherwise match the queried properties and all such labels to be excluded; if no schema label declares those properties, the query raises `NoIndexException`. Please define candidates before visibility filtering and state this condition across the EN/CN Vertex and Edge pages. ########## content/en/docs/clients/restful-api/vertex.md: ########## @@ -367,14 +367,34 @@ 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 (`P.eq` and +`P.within` count as exact values), the query looks up the vertex by ID and checks additional property conditions on that vertex without a property index. +If all primary-key fields have conditions but any of them is not an exact value (`P.neq`, `P.gt`, `P.between`, `P.textcontains` and similar), the query is +rejected before property-index lookup, even if a matching property index exists. Review Comment: ⚠️ Important: This says every non-exact primary-key condition is rejected, but the PRIMARY_KEY fast path calls `userpropValuesString()`, which explicitly accepts `RelationType.CONTAINS`. The REST predicate parser maps `P.contains` to that relation, and multi-valued primary-key properties are not rejected by schema validation; a contains query can therefore build an ID from one member and miss the stored vertex instead of returning the promised error. Please handle `P.contains` separately here and in Chinese, or reject it before the optimizer takes the primary-key path. -- 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]
