Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wiping materialized views (… WITH NO DATA) #421

Open
skalee opened this issue Jul 23, 2024 · 2 comments
Open

Wiping materialized views (… WITH NO DATA) #421

skalee opened this issue Jul 23, 2024 · 2 comments

Comments

@skalee
Copy link

skalee commented Jul 23, 2024

I propose adding another method which will wipe (depopulate) materialized views.

Rationale

It's needed in tests. Without wiping materialized views, at least in PostgreSQL, data these views are populated with may leak from one test to another, causing incorrect test behavior. For this reason, all materialized views should be depopulated in some setup or teardown hook.

Feature description

The new feature is about calling REFRESH MATERIALIZED VIEW <matviewname> WITH NO DATA.

I propose doing either of following:

  1. adding a brand new API method that depopulates a view. It could be named e.g. #wipe_materialized_view, #clear_materialized_view, #depopulate_materialized_view
  2. adding another keyword parameter to existing #refresh_materialized_view method. A new option could be named e.g. depopulate, no_data.

I am not sure if concurrent and cascade options that are currently available make sense in this context, but likely yes.

Further considerations

I believe it is worth to consider yet another method that wipes all defined materialized views. I am thinking about something similar to the pseudocode below:

names = execute_sql("SELECT matviewname FROM pg_matviews")
for name in names
  execute_sql("REFRESH MATERIALIZED VIEW " + name + " WITH NO DATA")
end
@derekprior
Copy link
Contributor

I can see how this would be useful, but if I had a lot of materialized views I might find this step wasteful (assuming it was part of setup or teardown between each test) if it were to operate on every materialized view indiscriminately.

On one hand, we could do something like this:

  1. Adding support for no_data: true to Scenic.database.refresh_materialized_view
  2. Exposing this option in the templated model that gets written with the scenic model generator
  3. Exposing #materialized_views or #views(materialized: true) to the adapter so you can programatically get all meterialized views
  4. Adding a test helper that has to be manually required/called that exposes something like clear_materialized_views (maybe optionally taking a list of names or something).

On the other hand, if you're finding it useful to wipe materialized views in your tests, that means you need to populate them in your tests when needed as well. So while we can help you be resetting state, you still need to refresh when you need correct contents... so what did you gain by wiping them in the first place?

@calebhearth
Copy link
Contributor

calebhearth commented Aug 23, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants