Add storage_parameters to PGMaterializedView

[dolfandringa]

This addresses #160
It adds the optional storage parameters to materialized views.
I also took the liberty of using fixtures instead of global variables in the test cases. This allows for parametrization of the tests for multiple test cases.
The use-case for me is for use with timescaledb continuous aggregates.

[olirice]

I'm sorry for not following up on the issue directly but I don't currently have the bandwidth to accept new features into alembic_utils

I'd recommend forking if you need this functionality, or you can maintain a copy of you adjusted PGMaterializedView in the project you're working on it should just work, but I haven't explicitly tested

[dolfandringa]

I'm sorry for not following up on the issue directly but I don't currently have the bandwidth to accept new features into alembic_utils

I'd recommend forking if you need this functionality, or you can maintain a copy of you adjusted PGMaterializedView in the project you're working on it should just work, but I haven't explicitly tested

@olirice
This is a shame. I am trying to help with the bandwidth issue by adding code and the PR/functionality isn't large. Instead of everyone making/maintaining their own libraries it's much more efficient for everyone if we join forces on a single one. Instead of spending time on maintaining my own library I could assist you.
Bascally if this doesn't get included here, it meas me forking it, but then I might as well make a fully new library with stuff that I need for timescaledb, that I was going to build on top of alembic_utils with this PR. I'd rather contribute back to your library then copy your code (which is quite good) into a new library and maintain that myself.

[olirice]

or you can maintain a copy of you adjusted PGMaterializedView

If you add your subclass'ed PGMaterializedView to your import path and use it instead of the stock one it "should" just work

Migrations have an incredibly high bar for absolute stability since they stick around un-edited for years. I'm not comfortable accepting any changes that I haven't reviewed and tested exhaustively and personally in case an edge case breaks existing users. Not sure how it happened but this project somehow has thousands of users and not breaking them is the highest priority

I'd transition the project to an established contributor if there were one

Sorry again, I've been on the other side of this convo and know how frustrating it is. Forking under a new name would be the best option if you plan to make multiple changes

[jrmalin]

I'm sorry for not following up on the issue directly but I don't currently have the bandwidth to accept new features into alembic_utils
I'd recommend forking if you need this functionality, or you can maintain a copy of you adjusted PGMaterializedView in the project you're working on it should just work, but I haven't explicitly tested

@olirice This is a shame. I am trying to help with the bandwidth issue by adding code and the PR/functionality isn't large. Instead of everyone making/maintaining their own libraries it's much more efficient for everyone if we join forces on a single one. Instead of spending time on maintaining my own library I could assist you. Bascally if this doesn't get included here, it meas me forking it, but then I might as well make a fully new library with stuff that I need for timescaledb, that I was going to build on top of alembic_utils with this PR. I'd rather contribute back to your library then copy your code (which is quite good) into a new library and maintain that myself.

@dolfandringa I have forked this and would be happy to include your contribution over at https://github.com/candidhealth/alembic-utils-extended