(Issue copied from GitLab.)
Currently, a search query dataclass can only implement either offset pagination (using the OffsetPaginationMixin) or cursor pagination (using the CursorPaginationMixin). Using both mixins in the same dataclass will (and should!) result in an error during class creation.
However, there are usecases where it makes sense to allow both styles of pagination in the same API, and let the client decide which pagination to use.
One possible way to implement this would be to write a third pagination mixin class, e.g. DynamicPaginationMixin, which implements offset and cursor pagination and decides which one to use depending on the search query arguments:
- If
start is set, use cursor pagination.
- If
offset is set, use offset pagination.
- If both are set, raise an error.
- If none of them are set, but pagination is required, choose one of the pagination types as the default. (TO REFINE: Which would be the better default?)
Also, if cursor pagination is used, it is not possible to sort the results (other than by the cursor column). It would be ideal if the user got an error message when they tried to use cursor pagination and sorting. However, this might be a bit difficult because (when the SortingMixin is used) sorted_by always has a default. If this default lines up with the cursor column (which it usually does), that wouldn't matter, but the defaults can be changed. It might be easier (and still acceptable) to simply ignore the sorted_by column.
It should also be prevented that the new mixin is used in combination with one of the other pagination mixins.
(Issue copied from GitLab.)
Currently, a search query dataclass can only implement either offset pagination (using the
OffsetPaginationMixin) or cursor pagination (using theCursorPaginationMixin). Using both mixins in the same dataclass will (and should!) result in an error during class creation.However, there are usecases where it makes sense to allow both styles of pagination in the same API, and let the client decide which pagination to use.
One possible way to implement this would be to write a third pagination mixin class, e.g.
DynamicPaginationMixin, which implements offset and cursor pagination and decides which one to use depending on the search query arguments:startis set, use cursor pagination.offsetis set, use offset pagination.Also, if cursor pagination is used, it is not possible to sort the results (other than by the cursor column). It would be ideal if the user got an error message when they tried to use cursor pagination and sorting. However, this might be a bit difficult because (when the
SortingMixinis used)sorted_byalways has a default. If this default lines up with the cursor column (which it usually does), that wouldn't matter, but the defaults can be changed. It might be easier (and still acceptable) to simply ignore thesorted_bycolumn.It should also be prevented that the new mixin is used in combination with one of the other pagination mixins.