Jonathan Sinovassin-Naïk created UNOMI-984:
----------------------------------------------

             Summary: 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



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)

Reply via email to