dorosch
Resuscitating this laudable work
This effort seriously needs to live, but this repo seems to be clearly dead. Maybe it's about time for a fork that incorporates the open PRs, maybe even extending the list of supported TimescaleDB functions? Unless someone is already doing it, I'm willing to move this forward. Tagging some of the latest commenters, PR authors to have a better sense of the general interest: @AntiSol @fellnerse @MRigal @MidCheck @RobRoyce @diorcety @DiddiZ
CC: @dorosch
howdy @snitramodranoel
I agree!
I've taken on maintenance of my fork. It's been low-activity due to my lack of time, but I'd welcome your input. Just the other day I moved my repo over to gitlab, which is where I tend to host things:
https://gitlab.com/AntiSol/sqlalchemy-timescaledb
I'd say that's the best place to continue development.
Yes, I'd like to see addition of more supported timescaledb functions. And a while back I read through all the open PRs and IIRC I was mostly fairly happy to accept them. Your contributions would be very welcome, too!
Feel free to HMU by raising issues/PRs on the gitlab 👍
That does look pretty cool, I like some of the things in this approach.
However:
- I'd be surprised if this will work with alembic, which for me is a dealbreaker. Part of the work I did was aimed at making sure it works with alembic
- IMO treating timescaledb as a separate sqlalchemy dialect is a cleaner solution overall rather than using your own specific classes and functions for everything, and i think due to that it's likely to be more compatible long term and as your project grows. Also note that when using it as a separate dialect you can switch dialects and have your codebase support both postgres and timescaledb (as long as you keep note of which functions are timescale-only). This is something I did successfully in the project I did this work for.
@snitramodranoel if you do end up using that library I'd be interested in hearing how it goes! 😄