refactoring to create dynamic request model #213
Conversation
|
@rsmith013 what's the state of the PR? I'm curious if this is required with the recent move away from stac-pydantic, and also change in #271 to allow for custom search models to be used. |
|
@lossyrob I got as far as the changes required to the pgstac and sqlalchemy backends. As I don't use them, I wouldn't have a way to check that they were working properly. I can try and make the changes and then others can verify. I'll take a deeper look at the other PR but this PR is about providing a framework where you don't need to define custom search models. The auto-generated docs reflect the implemented extensions. This means that without any enabled extensions /search just provides basic stac parameters then implementing sort extension automatically adds the sort parameter, adding the filters extension automatically adds the filters parameter, etc... It was about not baking in a particular implementation of the stac API and getting it to react to the enabled extension classes. I will see if I can find time to update with master and push it to completion. |
…nto issue/203/dynamic-search-model
|
@lossyrob This should be all done now. Let me know if you want anything changed. |
…nto issue/203/dynamic-search-model
…nto issue/203/dynamic-search-model
Fixed tests for sqlalchemy.
Changed instances of id to collection_id to make it explicit. Also removed the kwargs methods
from the url models. These were being used to change the value to id.
If this is required, it would be required to use
def kwargs(self):
return {
**self.kwargs(),
'stuff':'to override'
}
|
@moradology I have added a changelog entry and merged master. I have held fire on moving the operator class for the reasons mentioned in the thread from your comment. |
closes #203
I haven't made any changes to the sqlalchemy or pgstac modules. As I am not using either of them, I think it would be better for someone who is actively using them to try out the changes and make adjustments.
I have ended up with a Pydantic model for POST and an
APIRequestfor GET. This doesn't sit super comfortable but it seems necessary based on various threads on forums (e.g. this one) which suggest that Pydantic is not appropriate for query params.What's new?
This PR defines GET and POST request models for the extensions as well as pulling the pagination model out of the base. This should allow much more flexibility for implementation. Declared extensions are mixed together to create a dynamic request model which is rendered in the docs as query params for GET and body for POST.