jsinovassin opened a new pull request, #866:
URL: https://github.com/apache/unomi/pull/866

   Fixes UNOMI-984, at https://issues.apache.org/jira/browse/UNOMI-984
   
   ### What this changes
   
   One section is added to 
`manual/src/main/asciidoc/migrations/migrate-3.0-to-3.1.adoc`, under "Updating 
applications consuming Unomi". It records how 3.1 answers a search condition 
whose type it cannot resolve.
   
   ### Evidence
   
   `ProfileServiceImpl.doSearch` resolves the condition of a `Query` by its 
type. On 3.1 a condition with no resolvable type answers an empty list:
   
   ```java
   if (query.getCondition().getConditionType() == null) {
       LOGGER.warn("Cannot execute query: condition type '{}' could not be 
resolved", query.getCondition().getConditionTypeId());
       return new PartialList<>();
   }
   ```
   
   On `unomi-3.0.x` the same body ran the query with no condition at all, which 
returned every item:
   
   ```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
   }
   ```
   
   Measured on 3.1.0-SNAPSHOT, against `/cxs/profiles/search/sessions`:
   
   ```
   condition: {}                                 -> totalSize 0
   condition: {"type":"matchAllCondition", ...}  -> totalSize 196
   ```
   
   Every endpoint that takes a `Query` is affected, among them 
`/cxs/profiles/search`, `/cxs/profiles/search/sessions` and 
`/cxs/profiles/personas/search`.
   
   ### Why a note and not a revert
   
   The two answers are opposite, and neither the request nor the response says 
which one the caller got. Only the server log does. Running a query whose 
condition could not be resolved widens the search in silence. The 3.1 answer is 
therefore the safer of the two, and it deserves a migration note rather than a 
change of behaviour.
   
   ### Mechanism
   
   The section gives a two-column table of the 3.0 and 3.1 answers, and it 
names the endpoints the change reaches. It then shows the `matchAllCondition` 
body a client sends to search over everything. It sits next to the 
client-facing hardening section, which already records the other behaviour 
changes of 3.1.
   
   ### Notes for the reviewer
   
   This pull request changes documentation only, and no code.
   
   A client that omits the `condition` field entirely still searches over 
everything, so the note tells that client it needs no change.
   


-- 
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]

Reply via email to