[
https://issues.apache.org/jira/browse/UNOMI-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1003:
-------------------------------
Description:
h3. Summary
Two problems affect the lists of segments and scorings:
* The requested sort order is ignored, so items come back in a random order.
* With POST /cxs/segments/query or POST /cxs/scoring/query, if the limit is
missing or is -1 (which should mean "all"), the call fails with a server error
as soon as at least one item matches.
Both problems are new in 4.0. They came with the change that merges system
items and tenant items into one list.
The goal of this ticket is that these lists are sorted as requested, and that
"no limit" returns every match.
h3. Ways to explore
* Sort the merged list before taking the requested page.
* Sort only on a known list of fields (such as id, name and dates), and refuse
others.
* Treat a missing or negative limit as "all", up to the same maximum page size
used elsewhere, so one request cannot load an unlimited list.
h3. How to test
Manual check: create several segments and scorings, then query them with a
sort, with no limit, and with a limit of -1.
Automated tests to add, for both segments and scorings, with items in both the
"system" tenant and a normal tenant. Each must fail on the 4.0.0 release
candidate and pass once the fix is in:
* Unit tests for the sort: ascending and descending, by name and by date,
across the merged list.
* Unit tests for the page: no limit, a limit of -1, a limit of 0, a limit
larger than the total, and an offset past the end. Going through all pages
returns every item once, with no gaps or duplicates.
* A unit test that a sort on an unknown field is refused, and that "all" never
returns more than the maximum page size.
* An integration test of POST /cxs/segments/query and POST /cxs/scoring/query
with no limit: the answer is 200 with the full list.
was:
h3. Summary
Two problems affect the lists of segments and scorings:
* The requested sort order is ignored, so items come back in a random order.
* With POST /cxs/segments/query or POST /cxs/scoring/query, if the limit is
missing or is -1 (which should mean "all"), the call fails with a server error
as soon as at least one item matches.
Both problems are new in 4.0. They came with the change that merges system
items and tenant items into one list.
The goal of this ticket is that these lists are sorted as requested, and that
"no limit" returns every match.
h3. Ways to explore
* Sort the merged list before taking the requested page.
* Sort only on a known list of fields (such as id, name and dates), and refuse
others.
* Treat a missing or negative limit as "all", up to the same maximum page size
used elsewhere, so one request cannot load an unlimited list.
h3. How to test
Create several segments and scorings. Query them with a sort, with no limit,
and with a limit of -1. Check the order and the number of results.
> Segment and scoring lists ignore the sort, and fail with no limit
> -----------------------------------------------------------------
>
> Key: UNOMI-1003
> URL: https://issues.apache.org/jira/browse/UNOMI-1003
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Major
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> Two problems affect the lists of segments and scorings:
> * The requested sort order is ignored, so items come back in a random order.
> * With POST /cxs/segments/query or POST /cxs/scoring/query, if the limit is
> missing or is -1 (which should mean "all"), the call fails with a server
> error as soon as at least one item matches.
> Both problems are new in 4.0. They came with the change that merges system
> items and tenant items into one list.
> The goal of this ticket is that these lists are sorted as requested, and that
> "no limit" returns every match.
> h3. Ways to explore
> * Sort the merged list before taking the requested page.
> * Sort only on a known list of fields (such as id, name and dates), and
> refuse others.
> * Treat a missing or negative limit as "all", up to the same maximum page
> size used elsewhere, so one request cannot load an unlimited list.
> h3. How to test
> Manual check: create several segments and scorings, then query them with a
> sort, with no limit, and with a limit of -1.
> Automated tests to add, for both segments and scorings, with items in both
> the "system" tenant and a normal tenant. Each must fail on the 4.0.0 release
> candidate and pass once the fix is in:
> * Unit tests for the sort: ascending and descending, by name and by date,
> across the merged list.
> * Unit tests for the page: no limit, a limit of -1, a limit of 0, a limit
> larger than the total, and an offset past the end. Going through all pages
> returns every item once, with no gaps or duplicates.
> * A unit test that a sort on an unknown field is refused, and that "all"
> never returns more than the maximum page size.
> * An integration test of POST /cxs/segments/query and POST /cxs/scoring/query
> with no limit: the answer is 200 with the full list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
