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)