[
https://issues.apache.org/jira/browse/UNOMI-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Sinovassin-Naïk reassigned UNOMI-984:
----------------------------------------------
Assignee: Jonathan Sinovassin-Naïk
> Document the 3.1 answer to a search condition with no resolvable type
> ---------------------------------------------------------------------
>
> Key: UNOMI-984
> URL: https://issues.apache.org/jira/browse/UNOMI-984
> Project: Apache Unomi
> Issue Type: Bug
> Reporter: Jonathan Sinovassin-Naïk
> Assignee: Jonathan Sinovassin-Naïk
> Priority: Major
>
> Apache Unomi 3.1 changed how a search answers a condition it cannot resolve,
> and the migration guide
> does not record the change.
> {{ProfileServiceImpl.doSearch}} resolves the condition of a {{Query}} by its
> type. In 3.1 a condition
> with no resolvable type answers an empty list:
> {code:java}
> if (query.getCondition().getConditionType() == null) {
> LOGGER.warn("Cannot execute query: condition type '{}' could not be
> resolved", query.getCondition().getConditionTypeId());
> return new PartialList<>();
> }
> {code}
> 3.0 ran the query with no condition at all, which returned every item:
> {code:java}
> if (query.getCondition() != null &&
> definitionsService.resolveConditionType(query.getCondition())) {
> // run the query with the condition
> } else {
> // run the query with no condition, which returns every item
> }
> {code}
> The two answers are opposite. A client that sent {{"condition": {}}} read
> every item on 3.0 and reads
> an empty list on 3.1.
> h2. Why this is worth recording rather than reverting
> Running a query whose condition could not be resolved widens the search
> silently, so the 3.1 answer
> is the safer one. The behaviour is still a breaking change for a client, and
> neither the request nor
> the response says which answer it got. Only the server log does.
> h2. Endpoints affected
> Every endpoint that takes a {{Query}}, among them:
> * {{/cxs/profiles/search}}
> * {{/cxs/profiles/search/sessions}}
> * {{/cxs/profiles/personas/search}}
> h2. Steps to reproduce
> # Start Apache Unomi 3.1.0-SNAPSHOT with at least one session stored.
> # Post a search with an empty condition to {{/cxs/profiles/search/sessions}}:
> {code:json}
> { "text": "", "offset": 0, "limit": 10, "condition": {} }
> {code}
> # Post the same search with an explicit match-all condition:
> {code:json}
> { "text": "", "offset": 0, "limit": 10,
> "condition": { "type": "matchAllCondition", "parameterValues": {} } }
> {code}
> h2. Result
> {noformat}
> condition: {} -> totalSize 0
> condition: {"type":"matchAllCondition", ...} -> totalSize 196
> {noformat}
> h2. Proposed change
> Add a section to
> {{manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc}}, under
> "Updating
> applications consuming Unomi", next to the client-facing hardening section
> that records the other
> behaviour changes of 3.1. The section states what changed, which endpoints it
> reaches, and how a
> client states {{matchAllCondition}} to search over everything.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
