-
Notifications
You must be signed in to change notification settings - Fork 54
Add programmatic APIs for TimescaleDB (retention policy and compression) #56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add programmatic APIs for TimescaleDB (retention policy and compression) #56
Conversation
This commit adds support for TimescaleDB's retention policy and compression features: - Add RetentionPolicy class with methods to add and remove retention policies - Add CompressionPolicy class with methods to enable compression, add/remove policies, and get stats - Extend TimescaleManager with methods for managing retention and compression - Add comprehensive tests using TransactionTestCase for self-contained testing - Update README with examples of how to use the new APIs, including in migrations These APIs provide a programmatic way to manage TimescaleDB's data lifecycle features. The implementation uses a method-based approach where you call methods on the `timescale` manager, rather than a declarative approach in model definitions. Part of Milestone 2 roadmap. roadmap. Ref: jamessewell#23
|
@jamessewell is anyone able to review this? |
|
I'm looking for something like this right now, but I was wondering if this should be coming from the model |
My changes were a PoC (Proof of Concept), and the referenced issue/roadmap spoke about declaring it in models as migrations as a future addition, in ADDITION to my PoC that I've attempted (API, not migration based, but you can declare in your migration files manually if you check my readme) with passing tests. But this would take considerable effort (on my part), if maintainer won't even look at my PR then I won't bother.... I am maintaining my TimescaleDB tables manually outside of Django. If people actually expressed interest, I could take more time on it..... since I have a project that needs these missing features..... and a big effort to contribute these features, when I need them now (easier to do it myself, outside of this project), especially if not reviewed/merged, etc... |
|
Oooh! Neat! So this is similar to the way these other libs work right? |
Hi @jamessewell, Yes, my implementation is similar in approach to the TimescaleDB Ruby and TypeScript libraries, but with some differences due to Django's architecture (and my time constraints if this PR is not of interest to this repo): Similarities to timescaledb-ruby and timescaledb-ts:
Key differences:
Future enhancements: As mentioned in the roadmap (issue #23), a future enhancement could add declarative configuration in model definitions, similar to how the Ruby gem allows configuration in model classes: This would be a natural evolution of the current programmatic API, providing users with both options depending on their preference. Django model declarative approach would be a next step (and more work). Feel free to give a test and/or feedback. I am managing these features outside of Django on my project, so is a pain point - but I also need these now. How I'm currently managing and configuring TimescaleDB tables with outside of this package: Validation as management command: |
|
Oh there is this one too. https://github.com/jmitchel3/timescaledb-python This all sounds great. I will try to get a review done this week. I'd love to learn more about your project - if you want to chat join the TimescaleDB Slack :) |
This commit adds support for TimescaleDB's retention policy and compression features:
These APIs provide a programmatic way to manage TimescaleDB's data lifecycle features. The implementation uses a method-based approach where you call methods on the
timescalemanager, rather than a declarative approach in model definitions.Part of Milestone 2 roadmap. roadmap. Ref: #23