bitflicker64 commented on code in PR #503: URL: https://github.com/apache/hugegraph-doc/pull/503#discussion_r4307094373
########## content/en/docs/clients/restful-api/vertex.md: ########## @@ -367,14 +367,29 @@ 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 and checks additional property conditions on that vertex without a property index. If all primary-key fields have conditions but any of them +uses a range condition, the query is rejected before property-index lookup, even if a matching property index exists. Review Comment: Minor: "any of them uses a range condition, the query is rejected" is broader than the server behaviour, because the table on this page lists `P.eq` and `P.within` as range-matching expressions and neither is rejected on a primary-key field. At apache/hugegraph#3243 head 83ac535: - `P.eq(x)` becomes an `EQ` relation (`TraversalUtil.convCompare2Relation`), which `ConditionQuery.userpropValuesString()` accepts. - `P.within(a,b)` becomes an `IN` relation on the property (`TraversalUtil.convIn2Relation`). `GraphTransaction.optimizeQueries()` calls `ConditionQueryFlatten.flatten()` before `optimizeQuery()`, and `convIn2Or()` always turns a userprop `IN` into `EQ` branches (it keeps `IN` only for `OWNER_VERTEX`/`ID`). Each branch then takes the primary-key `IdQuery` path. - Only relations other than `EQ`/`CONTAINS` reach the `E.checkState` in `userpropValuesString()`: `P.neq`, `P.gt`/`P.gte`/`P.lt`/`P.lte`, `P.between`/`P.inside`/`P.outside`, and `P.textcontains`. So `GET .../vertices?label=person&properties={"name":"P.within(\"marko\",\"josh\")"}` on a label whose primary key is `name` returns both vertices by ID lookup, while a reader of this sentence would expect it to be rejected. Requested change: name the rejected predicates instead of "range condition", for example "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 ... `P.eq` and `P.within` count as exact values." Mirror it in content/cn/docs/clients/restful-api/vertex.md line 422 ("其中使用了范围条件"). -- 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]
