search

mypebble / django-pgviews

Fork of django-postgres that focuses on maintaining and improving support for Postgres SQL Views.
The Unlicense
195 stars 41 forks source link

Django 1.7 post migration hooks #4

Closed scott-w closed 9 years ago

scott-w commented 9 years ago

We need to use Django 1.7's post_migrate hooks because call_command('sync_pgviews') in tests makes them far too slow.

aberrier commented 5 years ago

This is actually a bad design. Materialized views can be really slow to generate and find their power in the fact that we can only run the query once per day. Creating a signal just after the migration (and execute something really slow in the main thread) can significantly delay all commands coming after a manage.py migrate which affect the majority of Django applications in production. (migrate then execute the wsgi of django)

From my experience, we used django-pgviews in our production application and the creation of our materialized views made our services completely unavailable until we figured out that this came from the piece of code @scott-w created. No documentation and no logs at all for a code that can have such a huge impact on performance.

Really disappointed.

scott-w commented 5 years ago

Hey @aberrier Thanks for your feedback. This was introduced way before django-pgviews supported materialized views and we've seen clashes between these two features. See #38 for the latest status on this. If you can find a way to resolve this fix, I'd be more than happy to check it out and help you bring the change into the codebase.

I'd also happily accept and merge a PR with some information on how the views are re-generated so future users don't get stung by this unexpectedly.

martyzz1 commented 4 years ago

https://github.com/mikicz/django-pgviews/pull/3

just make the ./manage sync_pgviews --update do the right thing... e.g. runs if the view doesn't exist - e.g. first deployment. But will be a no-op on subsequent deployments