Record view dependencies and recreate dependent views when needed

[dolfandringa]

For discussion:
I am using DBViews where one view selects data from another view. In my use-case I do it because we have complex JSONB data in a (PostgreSQL) field that I am selecting and deconstructing to tabular data, which i then select from in multiple other views.
In the DependentView i am then using f"SELECT ... FROM {MainView._meta.db_table}". This creates a problem when i want to change MainView later on since that view cant be dropped because DependentView depends on it. With a DROP CASCADE this could be solved, but then the DependentView would be gone.

One workaround for now is to manually modify the migrations by adding operations to first empty and then recreate the DependentView (in both directions)

What would be nicer though is if there would be a way to specify

class DependentView(DBView):
    depends_on=[MainView]

which would then make sure that if MainView changes, DependentView is first dropped, and then recreated after MainView is changed.

Does this sound like an interesting feature? If it does, I would be willing to put in time to contribute the code.

[BezBartek]

@dolfandringa
Hello, Thank you for the idea, it sounds good. I am happy to welcome new contributors!

I will try to illustrate what need to be done, to be sure that we understand each other.
If view B(dependent one) depends on view A:

• If view A definition changes, make migration with operations that drops views in order: view B, view A, then recreate in order: view A, view B. (created migration has 4 operations)
• Optional feature: add optional parameter to refresh method, if we refresh view A, refresh all dependent views (B).

Is it what we want here? If so, then feel free to start work, I am here to help you and review it.

To discuss:
What if view depends on regular table? I am fine with limiting that relation (dependency) to views only. But it would be a nice thing to consider here. It feels natural, that a view model can depend on both things.

[marcus905]

Let me chime in, if the change is on a table, and the views depend on it one of these two situations can happen:

• the view is defined with a callable (we can derive both field names and tables the view depends on via introspection): just do the drop/create as usual, with the alter table in between
• the view is defined as raw SQL (we cannot derive field names or table easily): warn the user that the field dependencies cannot be calculated and handled and so the migration might need to be manually adjusted, but proceed (OR, maybe also, make the hypothetical depends_on property a UNION of a list and dict, with the latter having a {'table':['field','field2',...],...} format if useful to manage that

In both cases, the view migration would need to have the ability to be "split" if we don't interact with the makemigrations machinery directly: makeviewmigrations, in these cases, should only do the DROPs, then warn you to make the normal migrations, and rerun the makeviewmigrations to add the CREATEs (or make another management command, maybe makeviewdropmigraitons|makeviewcreatemigrations and make the original makeviewmigration fail in any of those cases)

Another aspect that needs to be considered are Indexes for the materialized views that need to be created after the view is created.

Also, for a full dependency management, we'd need to create the dependency graph to do so to do multiple nested levels of drops and creates execute in the correct order.