GollumSF / rest-bundle / 33212588282

100%

master: 100%

push

github

Sortable collections: several keys, joins, whitelist and custom sorters

The `order` query parameter now takes several comma separated keys, each optionally
suffixed by its own direction, and dots cross relations:

    ?order=author:desc,title
    ?order=author.country.name:asc

The joins this needs are generated after the count query; two keys pointing at the
same relation share one join, and a relation already joined by the query callback is
reused.

#[ApiSortable] declares what a collection may be ordered by, on an entity property, on
the entity class, or on the controller action which may narrow the catalogue of the
entity. An entity declaring none keeps the historical permissive behaviour, so nothing
changes for an existing API. Declaring one turns the whitelist on and any other key is
answered with a 400.

Orderings no property path can express go through an ApiSorterInterface service,
referenced by class name from #[ApiSortable(sorter: ...)].

Resolution itself is a service, ApiOrderResolver, walking handlers tagged
gollumsf.rest.sort_resolver.handler by descending priority, so an application can own
keys of its own.

The `direction` query parameter still applies to the keys carrying no suffix but is
deprecated, and so is ApiFinderRepositoryInterface::apiFindBy() in favour of
ApiFinderOrderRepositoryInterface::apiFindByOrder(). A repository implementing the old
method by hand keeps working and receives the first key.

Also restores the exception handler the test kernel leaves behind, without touching the
error handler, which is what PHPUnit was reporting as risky.

279 of 279 new or added lines in 17 files covered. (100.0%)

834 of 834 relevant lines covered (100.0%)

22.44 hits per line