Seeking examples for materialized view index autogenerate change detection

[MoralCode]

Hello, Thank you so much for making this fork! The index support for materialized views that's mentioned in the README is how I found this repo.

I'm trying to improve how materialized views are versioned in https://github.com/chaoss/CollectOSS/. Many of these materialized views have simple unique indexes and I'm struggling a little bit with the documentation in this repo. The top of the README sounds like it describes what I need, but I cant find any examples or information that corresponds to what I'm trying to do.

The section of the README that talks about versioning indexes suggests that it is essentially a fix for Sqlalchemy 1.4 behavior, but since CollectOSS is on SQLAlchemy 2.0.22, i suspect this may no longer apply (at least according to my AI tool).

I'm trying to set things up such that:

1. Changes to the materialized view definitions are detected with --autogenerate
2. changes to only the indexes on the view can be detected with --autogenerate (or in combination with the view definitions)
3. Recreation of a materialized view (because its definition changed) can also add the indexes

The docs/examples.md only really looks at functions and I couldn't find any other helpful examples in the repo.

I wanted to reach out and ask whether this usecase is supported behavior and/or if you had a recommended way to go about setting this kind of behavior up.

other versions in use if it helps: alembic-utils-extended 1.5.0, Alembic 1.17.1.

Thanks,
Adrian

[morvayo]

there is an example in the v1.5.0 materialized view tests

they build Index("ix", "c1", unique=True) with sqlalchemy and pass it in the indexes list of PGMaterializedView before calling register_entities
both the create and definition change tests check for op.create_index in the generated migration

that covers creating indexes when the view is created or recreated
it is separate from the sqlalchemy 1.4 expression index workaround

the important limitation is your second requirement
the v1.5.0 entity comparison compares the view identity and definition
it does not compare the attached indexes list
changing only that list therefore does not trigger a view migration through register_entities alone

for index only changes use explicit op.create_index and op.drop_index operations in a revision unless you add a separate comparator
moving to sqlalchemy 2 does not by itself add that missing comparison to PGMaterializedView