Must be owner of materialized view mat_view_name about alembic_utils HOT 2 CLOSED

If I follow, the error is occurring while trying to autogenerated a new migration, not during deployment, correct?

Materialized views allows arbitrary SQL in their definitions, which is different from the entities alembic manages. To account for that, the diffing during autogenerate uses a separate workflow. When you create a materialized view in postgres it stores the underlying query. That query is parsed and reformatted so your local text blob in your python project no longer matches the text that is stored in postgres. That makes it difficult to determine if the definition has changed during --autogenerate

The way alembic_utils checks to see if the definition of a materialized view has changed is to:

1. look at the mat views current definition in the database
   and then, in a transaction:
2. drop the mat view
3. recreate the mat view from the local definition
4. check if the definition in the db is different than what we started with
5. roll back the transaction

The error your seeing is occurring at step 2 while alembic_utils is figuring out which (if any) of your local database entities have changed.

A solution to get you unblocked locally would be to manually execute

alter materialized view <mat view schema>.<mat view name> owner to <local migration role name>

to re-align the materialized view's owner to the role that produces the autogenerated migrations, but that shouldn't be necessary

Are you aware of any reason why the role name that is locally producing the migrations would differ from the role that applied the migrations to that local instance?

For example, spinning up your local development database from a dump of production where the role names are different would cause this

from alembic_utils.

Thank you for the explanation!

From your questions at the end I understand what I am doing wrong. You see, I am not connecting to a local development database, but running the alembic revision command while connecting directly to a hosted staging DB.

Because I was not aware of any sort of transaction actually being made I believed it to be a no-impact process and as such not needing a local dev DB (not best practices but hey :) ).

In the end what is happening is exactly what you described, the role that applies the migrations in staging is setup similarly to the one i mentioned on the original issue with a k8s job, so the role that applies the migration (remotely) is indeed different than the one that creates the migrations locally.

Guess I'll have to setup some best practices!
Thanks again!

from alembic_utils.