Oliver Rice

> is there a way I can have each module register their own entities? you'll want to keep the call to register_entities in `env.py` because - it should only be...

My concerns with any automatic registration approach are: - they fail unless the `ReplaceableEntity` is on an import path in `env.py` - less configurable / explicit So long as you...

hi again, Yes, I am interested in adding schema creation/dropping support. Maintaining schemas in migrations is typically low effort since they only need to be created once and don't require...

> I have no connection in env.py so I cannot check in genereate_views_from_metadata if my dependent tables are already created in the database or not. For `--autogenerate` support the view's...

Aggregate functions aren't currently supported The create statements are pretty similar, which makes it look like it'd be a small change to add, but aggregate functions' properties are stored in...

In addition to the alembic_utils test suite, I'm able to test postgres support on a multi-hundred entity codebase. That testing is often where subtle bugs are surfaced. Since I don't...

Re: mysql/mssql: whoops, thanks for the correction. Gotta work on those reading skills! I'd be interested to hear specifics about the changes you had to make to compare_registered_entities. Ideally it...

Hi, this is the same challenge as https://github.com/olirice/alembic_utils/issues/41 > This seems like a bug and splitting to separate migrations should not be necessary. I agree that it's clunky. The summary...

> first ignoring the registered entities, then a second time not ignoring the registered entities? (or perhaps this doesn't make sense, if for e.g. alembic upgrade needs to be run...

Yes "in" support is definitely on the roadmap Here's the full list of operators being considered https://postgrest.org/en/latest/api.html#operators