Comments (1)
For context, the initial postgresql application logic (PostgresCoreClient
et al) was written ~1 year ago in a different repo and refactored very slightly to accommodate the api layer which was added when this project was open sourced (#1). The original application used a FastAPI dependency to inject the required resources and code into the application.
There are some problems with the current implementation which are blocking development on other things (notably #57 #58 #64) - in no particular order:
PostgresClient
is overloaded. It defines methods for database operations like committing, checking if a row exists etc. but these are very opinionated and don't always work for our various use cases. Overloading of functionality in this particular class means we use it everywhere, even when it doesn't make much sense to do so. It's also just very abstracted, making development hard.- We are using
dataclass
when we really need to be usingattrs
. Mostly because attrs is more flexible when it comes to the definition of optional and optionally required attributes. - Defaulting to the sqlalchemy models defined by the library is weird and causes some not so intuitive behavior, especially when writing certain test cases (#70). It is also poor separation of concerns.
- I'm really on the fence about allowing sqlalchemy models to be instance attributes of a class. I'm not sure its bad, but I think there is a better way of doing it.
- The separation of pagination logic from the core is also very abstracted, and should be brought into core anyways to align with the spec (#67).
- Coupling of resource management and application logic makes #57 a nightmare.
What I'm going for with the refactor:
- Separation of resource management from application logic. This blog post has an interesting implementation using a mixin, not sure if we will take the same approach but its good food for thought. Sqlalchemy models, database configuration etc. are owned by the api layer and passed down to the application logic, preferably in a separate class which is responsible for resource management across the various backends.
- Don't worry about DRY. I'd rather have each database operation manage its own commits and deduplicate code as needed in the future. This should make the codebase much simpler, while making it obvious where abstraction of database operations really adds value.
- Use the newest version of sqlalchemy with support for async (#64)
I do think the base clients which define the interfaces are good, they follow the spec which is all that matters. Just that our postgres/canonical implementation of this interface is currently not that great.
from stac-fastapi.
Related Issues (20)
- Upgrade fastapi version for Content-Type Header ReDoS HOT 1
- INFERRED_LINK_RELS is missing `items` links? HOT 1
- Datetime as null is not accepted by the STAC FASTAPI HOT 8
- Aliases in FilterExtensionGetRequest model are not working
- Simple search returns items onlly with properties.datetime field HOT 3
- Becoming a maintainer on this project HOT 5
- Examine if pr 442 introduces breaking changes HOT 2
- Document new enhanced middleware configuration options
- Cannot use custom fields in Items HOT 9
- Introduce a tool to bump all version strings across project before release
- Deprecate Context Extension module
- PUT "/collections/{collection_id}" throws "update_collection() missing 1 required positional argument: 'collection'" HOT 3
- Integration testing with key stac-fastapi backends HOT 5
- pin sub-modules (api/extensions) to specific version HOT 4
- Detect disabled extensions in requests HOT 2
- types in `BaseSearchGetRequest`?
- How to tell if search is for single datetime? (Should `str_to_interval` return a single value for that?) HOT 7
- Remove pystac HOT 1
- Authentication and authorization implementation HOT 2
- Ensure Optional `query` Field Defaults to None for Pydantic V2 Compatibility
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stac-fastapi.