New release

[kiksekage]

I wanted to use the lovely postgresql driver implemented by @nickeopti sometime back in March when it struck me that these changes werent included in the newest pypi release. Would the changes since 0.7.5 warrant a new release? 🙏

[j08lue]

Definitely! I'd say 0.8.0, actually, since we changed the internal API and introduced a new dependency (SQLAlchemy).

IMO 1.0.0 is also overdue, but let us discuss that separately. 😄

I wrote up the changelog - pls review @dionhaefner and @mrpgraae and feel free to push tha button if you approve.

What's Changed

• Added support for PostgreSQL databases via refactor to SQLAlchemy by @mrpgraae, @nickeopti, and @chapmanjacobd PostgreSQL Support #257, Re-add database user and password as settings, and rename from MYSQL_* to SQL_* #258, Test using postgresql meta store as well #260, Issue262 #263
• Dropped Python 3.6 support by @dionhaefner Python 3.6 is EOL #264
• Improved MySQL connection stability by @panakouris Fix MySQL connection drop #267
• Added example script by @tomalrussell Add a first example ingestion script to the docs #277
• Fixed APIdoc URL by @dionhaefner Fix apidoc url #278
• Fixed process pool by @dionhaefner use globals instead of threading.local (fixes #281) #282

Full Changelog: v0.7.5...main

[dionhaefner]

My personal opinion is that we should not release before having #245 sorted out. I have a half-finished implementation but no time to wrap it up. So how about any of the commercial users put some work into it? 🙃

[j08lue]

should not release before having #245 sorted out

Release 1.0 or release anything? This has been an issue long, so it is perhaps not a blocker for another 0. release?

how about any of the commercial users put some work into it

I am currently all booked on TiTiler https://developmentseed.org/titiler/ 😉

[mrpgraae]

My personal opinion is that we should not release before having #245 sorted out. I have a half-finished implementation but no time to wrap it up. So how about any of the commercial users put some work into it? 🙃

@dionhaefner I can do that. I have been using Yoyo Migrations for work recently and I really like it. It's very light-weight and supports all the databases that Terracotta supports. Would you take a look and see if you think we could use it?

[dionhaefner]

Release 1.0 or release anything? This has been an issue long, so it is perhaps not a blocker for another 0. release?

I am uneasy with making any release that breaks current deployments without an easy way to fix it. It doesn't have to be an all-in migration system but at the very least we should have a script people can run to migrate this time.

[dionhaefner]

I have been using Yoyo Migrations for work recently and I really like it. It's very light-weight and supports all the databases that Terracotta supports.

Looks fine to me, definitely better than alembic. I started writing a simple framework that operates on pure SQL, which would be sufficient in our case (main...migration). But if you have a simple framework that supports everything we need, including for example re-naming SQLite tables, I wouldn't object.

[j08lue]

I am uneasy with making any release that breaks current deployments without an easy way to fix it.

Right, I guess none of our past releases changed the database model - but the deployments would still break when you updated, because the version comparison would throw an error. Anyways - awesome if you can move this forward, @mrpgraae!

[dionhaefner]

I expanded my simple migration script to finally unblock this. Still happy for contributions that switch that out for something more sophisticated.