Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add statement about of Pageable to documentation
See original GitHub issueIssue Description
Setup information hikaku version: 2.0.0-SNAPSHOT implementation converter: SpringConverter
Describe the bug Spring data supports the idea of Pageable. A pageable is an object build by request parameter, supporting page, size and sort (parameter names are changeable). These parameters might be part of an api, but are not explizit mapped to query parameter. The documentation says “Query Parameter based on an object” are not supported, but I think a Pageable should be mentioned explizitly.
Expected behavior Add support for Pageable or add a note that Pageable are currently not supported in hikaku.
Code samples: Can you provide specifications or code snippets?
public ResponseEntity<Person> getPersons(
@RequestParam(name = "language", required = false) String language,
@PageableDefault Pageable pageable) {
...
}
Issue Analytics
- State:
- Created 4 years ago
- Comments:5
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Hi @jrehwaldt, thank you for giving feedback on this topic.
First of all, as stated in the list of currently not supported features in the README.md of the spring converter, query parameter based on classes/interfaces are currently not supported in general. So depending on the solution for that, this might solve the cases mentioned above already. It might make sense to implement the general approach before we focus on specific interfaces or classes.
From my perspective the PagaeableDifferenceEvaluator idea wouldn’t work. Hikaku is designed to convert a specification or an implementation to an internal domain model of a REST endpoint. After that the model for the specification is compared to the model of the implementation in the core. At the time of the actual comparison, there is therefore no additional information about the implementation, such as class types and the like. This is intentional.
However I like the idea of creating rules dynamically for the config to ignore specific bits, instead of static rules.
As I see it the proposal from #47 unfortunately doesn’t solve either the general nor the original issue.
Pageableis an interface, which you excluded from your proposalsortcould be mapped tosortOrderinternally.A truly general solution would be to allow deriving arbitrary parameters from unknown objects declared in endpoint mappings, something like
(Object) -> Set<Parameter>, withParameterbeing any of these.