joerghoh opened a new pull request, #216: URL: https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/216
…rties in PagedQueryIterator Because `loadVanityPaths()` threw, `vanityPathsProcessed` was never set to `true`, so the cache stayed empty for the lifetime of the resolver. ## Root cause: query order vs. storage order `PagedQueryIterator` pages through query results and verifies, as a safety check, that they come back in ascending order. To do that it needs — for each resource — the single value the results are *ordered by*. It derived that value from the wrong source. Two orderings are in play, and they are not the same: 1. **The order of the query results.** The query sorts with `ORDER BY FIRST([sling:vanityPath])`. Oak's `FIRST()` returns the **lexicographically smallest** value of the (multivalued) property, so the repository returns resources ordered by the *minimum* value. 2. **The order of reading the ValueMap.** The iterator used `resource.getValueMap().get(propertyName)[0]` — the value at **array index 0**. The ValueMap returns values in *storage order*, which is arbitrary; index 0 is not necessarily the smallest value. For a single-valued property the two coincide, so the check worked. For a **multivalued** `sling:vanityPath` they diverge: the query sorts by the minimum, but the iterator compared against index 0. When a resource's index-0 value is larger than its minimum, the iterator sees an apparent "out of order" result and throws `QueryImplementationException` — even though the query order was correct. -- 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]
