Merge pull request #77 from themrinalsinha/feat/disable-sync-view-on-migrate

Resolves #76 Decouple post_migrate signal from refreshing the views

Author: mikicz

README.md

@@ -137,6 +137,14 @@ This will take all fields on `myapp.Customer` and apply them to
 
 ## Features
 
+### Configuration
+`MATERIALIZED_VIEWS_DISABLE_SYNC_ON_MIGRATE`
+
+When set to True, it skips running `sync_pgview` during migrations, which can be useful if you want to control the synchronization manually or avoid potential overhead during migrations. (default: False)
+```
+MATERIALIZED_VIEWS_DISABLE_SYNC_ON_MIGRATE = True
+```
+
 ### Updating Views
 
 Sometimes your models change and you need your Database Views to reflect the new
@@ -215,9 +223,9 @@ def customer_saved(sender, action=None, instance=None, **kwargs):
 
 Postgres 9.4 and up allow materialized views to be refreshed concurrently, without blocking reads, as long as a
 unique index exists on the materialized view. To enable concurrent refresh, specify the name of a column that can be
-used as a unique index on the materialized view. Unique index can be defined on more than one column of a materialized 
-view. Once enabled, passing `concurrently=True` to the model's refresh method will result in postgres performing the 
-refresh concurrently. (Note that the refresh method itself blocks until the refresh is complete; concurrent refresh is 
+used as a unique index on the materialized view. Unique index can be defined on more than one column of a materialized
+view. Once enabled, passing `concurrently=True` to the model's refresh method will result in postgres performing the
+refresh concurrently. (Note that the refresh method itself blocks until the refresh is complete; concurrent refresh is
 most useful when materialized views are updated in another process or thread.)
 
 Example:
@@ -245,7 +253,7 @@ def customer_saved(sender, action=None, instance=None, **kwargs):
 
 #### Indexes
 
-As the materialized view isn't defined through the usual Django model fields, any indexes defined there won't be 
+As the materialized view isn't defined through the usual Django model fields, any indexes defined there won't be
 created on the materialized view. Luckily Django provides a Meta option called `indexes` which can be used to add custom
 indexes to models. `pg_views` supports defining indexes on materialized views using this option.
 
@@ -265,7 +273,7 @@ class PreferredCustomer(pg.MaterializedView):
 
     name = models.CharField(max_length=100)
     post_code = models.CharField(max_length=20, db_index=True)
-    
+
     class Meta:
         managed = False  # don't forget this, otherwise Django will think it's a regular model
         indexes = [
@@ -277,7 +285,7 @@ class PreferredCustomer(pg.MaterializedView):
 
 Materialized views can be created either with or without data. By default, they are created with data, however
 `pg_views` supports creating materialized views without data, by defining `with_data = False` for the
-`pg.MaterializedView` class. Such views then do not support querying until the first 
+`pg.MaterializedView` class. Such views then do not support querying until the first
 refresh (raising `django.db.utils.OperationalError`).
 
 Example:
@@ -304,7 +312,7 @@ checks existing materialized view definition in the database (if the mat. view e
 definition with the one currently defined in your `pg.MaterializedView` subclass. If the definition matches
 exactly, the re-create of materialized view is skipped.
 
-This feature is enabled by setting the `MATERIALIZED_VIEWS_CHECK_SQL_CHANGED` in your Django settings to `True`, 
+This feature is enabled by setting the `MATERIALIZED_VIEWS_CHECK_SQL_CHANGED` in your Django settings to `True`,
 which enables the feature when running `migrate`. The command `sync_pgviews` uses this setting as well,
 however it also has switches `--enable-materialized-views-check-sql-changed` and
 `--disable-materialized-views-check-sql-changed` which override this setting for that command.
@@ -316,14 +324,14 @@ on change of the content but not the name.
 
 ### Schemas
 
-By default, the views will get created in the schema of the database, this is usually `public`. 
-The package supports the database defining the schema in the settings by using 
+By default, the views will get created in the schema of the database, this is usually `public`.
+The package supports the database defining the schema in the settings by using
 options (`"OPTIONS": {"options": "-c search_path=custom_schema"}`).
 
 The package `django-tenants` is supported as well, if used.
 
 It is possible to define the schema explicitly for a view, if different from the default schema of the database, like
-this: 
+this:
 
 ```python
 from django_pgviews import view as pg

django_pgviews/apps.py

@@ -44,4 +44,9 @@ def ready(self):
         """
         Find and setup the apps to set the post_migrate hooks for.
         """
-        signals.post_migrate.connect(self.sync_pgviews)
+        from django.conf import settings
+
+        sync_enabled = getattr(settings, "MATERIALIZED_VIEWS_DISABLE_SYNC_ON_MIGRATE", False) is False
+
+        if sync_enabled:
+            signals.post_migrate.connect(self.sync_pgviews)

tests/test_project/settings/base.py

@@ -174,3 +174,5 @@
         "django_pgviews": {"level": "INFO", "handlers": ["console"]},
     },
 }
+
+MATERIALIZED_VIEWS_SYNC_DISABLED = False

tests/test_project/viewtest/tests.py

@@ -3,14 +3,16 @@
 from contextlib import closing
 from datetime import timedelta
 
+from django.apps import apps
 from django.conf import settings
 from django.contrib import auth
 from django.contrib.auth.models import User
 from django.core.management import call_command
 from django.db import DEFAULT_DB_ALIAS, connection
+from django.db.models.signals import post_migrate
 from django.db.utils import DatabaseError, OperationalError
 from django.dispatch import receiver
-from django.test import TestCase
+from django.test import TestCase, override_settings
 from django.utils import timezone
 
 from django_pgviews.signals import all_views_synced, view_synced
@@ -438,3 +440,59 @@ def test_no_schema_list(self):
         where_fragment, params = _make_where(schemaname=None, tablename=["test_tablename1", "test_tablename2"])
         self.assertEqual(where_fragment, "tablename IN (%s, %s)")
         self.assertEqual(params, ["test_tablename1", "test_tablename2"])
+
+
+class TestMaterializedViewSyncDisabledSettings(TestCase):
+    def setUp(self):
+        """
+        NOTE: By default, Django runs and registers signals with default values during
+        test execution. To address this, we store the original receivers and settings,
+        then restore them in tearDown to avoid affecting other tests.
+        """
+
+        # Store original receivers and settings
+        self._original_receivers = list(post_migrate.receivers)
+        self._original_config = apps.get_app_config("django_pgviews").counter
+
+        # Clear existing signal receivers
+        post_migrate.receivers.clear()
+
+        # Get the app config and reset counter
+        config = apps.get_app_config("django_pgviews")
+        config.counter = 0
+
+        # Reload app config with new settings
+        with override_settings(MATERIALIZED_VIEWS_DISABLE_SYNC_ON_MIGRATE=True):
+            config.ready()
+
+        # Drop the view if it exists
+        with connection.cursor() as cursor:
+            cursor.execute("DROP MATERIALIZED VIEW IF EXISTS viewtest_materializedrelatedview CASCADE;")
+
+    def tearDown(self):
+        """Restore original signal receivers and app config state"""
+
+        post_migrate.receivers.clear()
+        post_migrate.receivers.extend(self._original_receivers)
+        apps.get_app_config("django_pgviews").counter = self._original_config
+
+    def test_migrate_materialized_views_sync_disabled(self):
+        self.assertEqual(models.TestModel.objects.count(), 0)
+
+        models.TestModel.objects.create(name="Test")
+
+        call_command("migrate")  # migrate is not running sync_pgviews
+        with connection.cursor() as cursor:
+            cursor.execute(
+                "SELECT EXISTS (SELECT 1 FROM pg_matviews WHERE matviewname = 'viewtest_materializedrelatedview');"
+            )
+            exists = cursor.fetchone()[0]
+            self.assertFalse(exists, "Materialized view viewtest_materializedrelatedview should not exist.")
+
+        call_command("sync_pgviews")  # explicitly run sync_pgviews
+        with connection.cursor() as cursor:
+            cursor.execute(
+                "SELECT EXISTS (SELECT 1 FROM pg_matviews WHERE matviewname = 'viewtest_materializedrelatedview');"
+            )
+            exists = cursor.fetchone()[0]
+            self.assertTrue(exists, "Materialized view viewtest_materializedrelatedview should exist.")