django-migrate-sql-deux 0.4.0__tar.gz → 0.5.2__tar.gz

django_migrate_sql_deux-0.5.2/LICENSE

@@ -0,0 +1,13 @@
+Copyright (c) 2016, Bogdan Klichuk <klichukb@gmail.com>
+
+Permission to use, copy, modify, and/or distribute this software for any
+purpose with or without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies.
+
+THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

django_migrate_sql_deux-0.5.2/PKG-INFO

@@ -0,0 +1,302 @@
+Metadata-Version: 2.4
+Name: django-migrate-sql-deux
+Version: 0.5.2
+Summary: Migration support for raw SQL in Django
+Home-page: https://github.com/festicket/django-migrate-sql
+Author: Festicket
+Author-email: dev@festicket.com
+License: BSD
+Classifier: Development Status :: 3 - Alpha
+Classifier: Framework :: Django
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: BSD License
+Classifier: Natural Language :: English
+Classifier: Programming Language :: Python :: 3.6
+Classifier: Programming Language :: Python :: 3.7
+Classifier: Framework :: Django :: 2.1
+Classifier: Framework :: Django :: 2.2
+Classifier: Framework :: Django :: 3.0
+License-File: LICENSE
+Dynamic: author
+Dynamic: author-email
+Dynamic: classifier
+Dynamic: description
+Dynamic: home-page
+Dynamic: license
+Dynamic: license-file
+Dynamic: summary
+
+django-migrate-sql-deux
+=======================
+
+.. note::
+
+    This package is a fork of the ``django-migrate-sql`` package, originally published
+    by Bogdan Klichuk. This package appears unmaintained, so we decided to start a fork
+    as we depended on it. Most of the code is from him.
+
+|Build Status| |codecov.io|
+
+Django Migrations support for raw SQL.
+
+About
+-----
+
+This tool implements mechanism for managing changes to custom SQL
+entities (functions, types, indices, triggers) using built-in migration
+mechanism. Technically creates a sophistication layer on top of the
+``RunSQL`` Django operation.
+
+What it does
+------------
+
+-  Makes maintaining your SQL functions, custom composite types, indices
+   and triggers easier.
+-  Structures SQL into configuration of **SQL items**, that are
+   identified by names and divided among apps, just like models.
+-  Automatically gathers and persists changes of your custom SQL into
+   migrations using ``makemigrations``.
+-  Properly executes backwards/forwards keeping integrity of database.
+-  Create -> Drop -> Recreate approach for changes to items that do not
+   support altering and require dropping and recreating.
+-  Dependencies system for SQL items, which solves the problem of
+   updating items, that rely on others (for example custom
+   types/functions that use other custom types), and require dropping
+   all dependency tree previously with further recreation.
+
+What it does not
+----------------
+
+-  Does not parse SQL nor validate queries during ``makemigrations`` or
+   ``migrate`` because is database-agnostic. For this same reason
+   setting up proper dependencies is user's responsibility.
+-  Does not create ``ALTER`` queries for items that support this, for
+   example ``ALTER TYPE`` in Postgre SQL, because is database-agnostic.
+   In case your tools allow rolling all the changes through ``ALTER``
+   queries, you can consider not using this app **or** restructure
+   migrations manually after creation by nesting generated operations
+   into ```state_operations`` of
+   ``RunSQL`` <https://docs.djangoproject.com/en/1.8/ref/migration-operations/#runsql>`__
+   that does ``ALTER``.
+-  (**TODO**)During ``migrate`` does not restore full state of items for
+   analysis, thus does not notify about existing changes to schema that
+   are not migrated **nor** does not recognize circular dependencies
+   during migration execution.
+
+Installation
+------------
+
+Install from PyPi:
+
+::
+
+    $ pip install django-migrate-sql-deux
+
+Add ``migrate_sql`` to ``INSTALLED_APPS``:
+
+.. code:: python
+
+    INSTALLED_APPS = [
+        # ...
+        'migrate_sql',
+    ]
+
+App defines a custom ``makemigrations`` command, that inherits from
+Django's core one, so in order ``migrate_sql`` app to kick in put it
+after any other apps that redefine ``makemigrations`` command too.
+
+Usage
+-----
+
+1) Create ``sql_config.py`` module to root of a target app you want to
+   manage custom SQL for.
+
+2) Define SQL items in it (``sql_items``), for example:
+
+.. code:: python
+
+    # PostgreSQL example.
+    # Let's define a simple function and let `migrate_sql` manage it's changes.
+
+    from migrate_sql.config import SQLItem
+
+    sql_items = [
+        SQLItem(
+            'make_sum',   # name of the item
+            'create or replace function make_sum(a int, b int) returns int as $$ '
+            'begin return a + b; end; ' 
+            '$$ language plpgsql;',  # forward sql
+            reverse_sql='drop function make_sum(int, int);',  # sql for removal
+        ),
+    ]
+
+3) Create migration ``./manage.py makemigrations``:
+
+   ::
+
+       Migrations for 'app_name':
+         0002_auto_xxxx.py:
+       - Create SQL "make_sum"
+
+You can take a look at content this generated:
+
+.. code:: python
+
+    # -*- coding: utf-8 -*-
+    from __future__ import unicode_literals
+    from django.db import migrations, models
+    import migrate_sql.operations
+
+
+    class Migration(migrations.Migration):
+        dependencies = [
+            ('app_name', '0001_initial'),
+        ]
+        operations = [
+            migrate_sql.operations.CreateSQL(
+                name='make_sum',
+                sql='create or replace function make_sum(a int, b int) returns int as $$ begin return a + b; end; $$ language plpgsql;',
+                reverse_sql='drop function make_sum(int, int);',
+            ),
+        ]
+
+4) Execute migration ``./manage.py migrate``:
+
+   ::
+
+       Operations to perform:
+         Apply all migrations: app_name
+       Running migrations:
+         Rendering model states... DONE
+         Applying app_name.0002_xxxx... OK
+
+Check result in ``./manage.py dbshell``:
+
+::
+
+    db_name=# select make_sum(12, 15);
+     make_sum 
+    ----------
+           27
+    (1 row)
+
+Now, say, you want to change the function implementation so that it
+takes a custom type as argument:
+
+5) Edit your ``sql_config.py``:
+
+.. code:: python
+
+    # PostgreSQL example #2.
+    # Function and custom type.
+
+    from migrate_sql.config import SQLItem
+
+    sql_items = [
+        SQLItem(
+            'make_sum',  # name of the item
+            'create or replace function make_sum(a mynum, b mynum) returns mynum as $$ '
+            'begin return (a.num + b.num, 'result')::mynum; end; '
+            '$$ language plpgsql;',  # forward sql
+            reverse_sql='drop function make_sum(mynum, mynum);',  # sql for removal
+            # depends on `mynum` since takes it as argument. we won't be able to drop function
+            # without dropping `mynum` first.
+            dependencies=[('app_name', 'mynum')],
+        ),
+        SQLItem(
+            'mynum'   # name of the item
+            'create type mynum as (num int, name varchar(20));',  # forward sql
+            reverse_sql='drop type mynum;',  # sql for removal
+        ),
+    ]
+
+6) Generate migration ``./manage.py makemigrations``:
+
+::
+
+    Migrations for 'app_name':
+      0003_xxxx:
+        - Reverse alter SQL "make_sum"
+        - Create SQL "mynum"
+        - Alter SQL "make_sum"
+        - Alter SQL state "make_sum"
+
+You can take a look at the content this generated:
+
+.. code:: python
+
+    # -*- coding: utf-8 -*-
+    from __future__ import unicode_literals
+    from django.db import migrations, models
+    import migrate_sql.operations
+
+
+    class Migration(migrations.Migration):
+        dependencies = [
+            ('app_name', '0002_xxxx'),
+        ]
+        operations = [
+            migrate_sql.operations.ReverseAlterSQL(
+                name='make_sum',
+                sql='drop function make_sum(int, int);',
+                reverse_sql='create or replace function make_sum(a int, b int) returns int as $$ begin return a + b; end; $$ language plpgsql;',
+            ),
+            migrate_sql.operations.CreateSQL(
+                name='mynum',
+                sql='create type mynum as (num int, name varchar(20));',
+                reverse_sql='drop type mynum;',
+            ),
+            migrate_sql.operations.AlterSQL(
+                name='make_sum',
+                sql='create or replace function make_sum(a mynum, b mynum) returns mynum as $$ begin return (a.num + b.num, \'result\')::mynum; end; $$ language plpgsql;',
+                reverse_sql='drop function make_sum(mynum, mynum);',
+            ),
+            migrate_sql.operations.AlterSQLState(
+                name='make_sum',
+                add_dependencies=(('app_name', 'mynum'),),
+            ),
+        ]
+
+***NOTE:** Previous function is completely dropped before creation
+because definition of it changed. ``CREATE OR REPLACE`` would create
+another version of it, so ``DROP`` makes it clean.*
+
+***If you put ``replace=True`` as kwarg to an ``SQLItem`` definition, it
+will NOT drop + create it, but just rerun forward SQL, which is
+``CREATE OR REPLACE`` in this example.***
+
+7) Execute migration ``./manage.py migrate``:
+
+::
+
+    Operations to perform:
+      Apply all migrations: app_name
+    Running migrations:
+      Rendering model states... DONE
+      Applying brands.0003_xxxx... OK
+
+Check results:
+
+::
+
+    db_name=# select make_sum((5, 'a')::mynum, (3, 'b')::mynum);
+      make_sum  
+    ------------
+     (8,result)
+    (1 row)
+
+    db_name=# select make_sum(12, 15);
+    ERROR:  function make_sum(integer, integer) does not exist
+    LINE 1: select make_sum(12, 15);
+                   ^
+    HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
+
+For more examples see ``tests``.
+
+Feel free to `open new
+issues <https://github.com/klichukb/django-migrate-sql/issues>`__.
+
+.. |Build Status| image:: https://travis-ci.org/klichukb/django-migrate-sql.svg?branch=master
+   :target: https://travis-ci.org/klichukb/django-migrate-sql
+.. |codecov.io| image:: https://img.shields.io/codecov/c/github/klichukb/django-migrate-sql/master.svg
+   :target: https://codecov.io/github/klichukb/django-migrate-sql?branch=master

django_migrate_sql_deux-0.5.2/django_migrate_sql_deux.egg-info/PKG-INFO

@@ -0,0 +1,302 @@
+Metadata-Version: 2.4
+Name: django-migrate-sql-deux
+Version: 0.5.2
+Summary: Migration support for raw SQL in Django
+Home-page: https://github.com/festicket/django-migrate-sql
+Author: Festicket
+Author-email: dev@festicket.com
+License: BSD
+Classifier: Development Status :: 3 - Alpha
+Classifier: Framework :: Django
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: BSD License
+Classifier: Natural Language :: English
+Classifier: Programming Language :: Python :: 3.6
+Classifier: Programming Language :: Python :: 3.7
+Classifier: Framework :: Django :: 2.1
+Classifier: Framework :: Django :: 2.2
+Classifier: Framework :: Django :: 3.0
+License-File: LICENSE
+Dynamic: author
+Dynamic: author-email
+Dynamic: classifier
+Dynamic: description
+Dynamic: home-page
+Dynamic: license
+Dynamic: license-file
+Dynamic: summary
+
+django-migrate-sql-deux
+=======================
+
+.. note::
+
+    This package is a fork of the ``django-migrate-sql`` package, originally published
+    by Bogdan Klichuk. This package appears unmaintained, so we decided to start a fork
+    as we depended on it. Most of the code is from him.
+
+|Build Status| |codecov.io|
+
+Django Migrations support for raw SQL.
+
+About
+-----
+
+This tool implements mechanism for managing changes to custom SQL
+entities (functions, types, indices, triggers) using built-in migration
+mechanism. Technically creates a sophistication layer on top of the
+``RunSQL`` Django operation.
+
+What it does
+------------
+
+-  Makes maintaining your SQL functions, custom composite types, indices
+   and triggers easier.
+-  Structures SQL into configuration of **SQL items**, that are
+   identified by names and divided among apps, just like models.
+-  Automatically gathers and persists changes of your custom SQL into
+   migrations using ``makemigrations``.
+-  Properly executes backwards/forwards keeping integrity of database.
+-  Create -> Drop -> Recreate approach for changes to items that do not
+   support altering and require dropping and recreating.
+-  Dependencies system for SQL items, which solves the problem of
+   updating items, that rely on others (for example custom
+   types/functions that use other custom types), and require dropping
+   all dependency tree previously with further recreation.
+
+What it does not
+----------------
+
+-  Does not parse SQL nor validate queries during ``makemigrations`` or
+   ``migrate`` because is database-agnostic. For this same reason
+   setting up proper dependencies is user's responsibility.
+-  Does not create ``ALTER`` queries for items that support this, for
+   example ``ALTER TYPE`` in Postgre SQL, because is database-agnostic.
+   In case your tools allow rolling all the changes through ``ALTER``
+   queries, you can consider not using this app **or** restructure
+   migrations manually after creation by nesting generated operations
+   into ```state_operations`` of
+   ``RunSQL`` <https://docs.djangoproject.com/en/1.8/ref/migration-operations/#runsql>`__
+   that does ``ALTER``.
+-  (**TODO**)During ``migrate`` does not restore full state of items for
+   analysis, thus does not notify about existing changes to schema that
+   are not migrated **nor** does not recognize circular dependencies
+   during migration execution.
+
+Installation
+------------
+
+Install from PyPi:
+
+::
+
+    $ pip install django-migrate-sql-deux
+
+Add ``migrate_sql`` to ``INSTALLED_APPS``:
+
+.. code:: python
+
+    INSTALLED_APPS = [
+        # ...
+        'migrate_sql',
+    ]
+
+App defines a custom ``makemigrations`` command, that inherits from
+Django's core one, so in order ``migrate_sql`` app to kick in put it
+after any other apps that redefine ``makemigrations`` command too.
+
+Usage
+-----
+
+1) Create ``sql_config.py`` module to root of a target app you want to
+   manage custom SQL for.
+
+2) Define SQL items in it (``sql_items``), for example:
+
+.. code:: python
+
+    # PostgreSQL example.
+    # Let's define a simple function and let `migrate_sql` manage it's changes.
+
+    from migrate_sql.config import SQLItem
+
+    sql_items = [
+        SQLItem(
+            'make_sum',   # name of the item
+            'create or replace function make_sum(a int, b int) returns int as $$ '
+            'begin return a + b; end; ' 
+            '$$ language plpgsql;',  # forward sql
+            reverse_sql='drop function make_sum(int, int);',  # sql for removal
+        ),
+    ]
+
+3) Create migration ``./manage.py makemigrations``:
+
+   ::
+
+       Migrations for 'app_name':
+         0002_auto_xxxx.py:
+       - Create SQL "make_sum"
+
+You can take a look at content this generated:
+
+.. code:: python
+
+    # -*- coding: utf-8 -*-
+    from __future__ import unicode_literals
+    from django.db import migrations, models
+    import migrate_sql.operations
+
+
+    class Migration(migrations.Migration):
+        dependencies = [
+            ('app_name', '0001_initial'),
+        ]
+        operations = [
+            migrate_sql.operations.CreateSQL(
+                name='make_sum',
+                sql='create or replace function make_sum(a int, b int) returns int as $$ begin return a + b; end; $$ language plpgsql;',
+                reverse_sql='drop function make_sum(int, int);',
+            ),
+        ]
+
+4) Execute migration ``./manage.py migrate``:
+
+   ::
+
+       Operations to perform:
+         Apply all migrations: app_name
+       Running migrations:
+         Rendering model states... DONE
+         Applying app_name.0002_xxxx... OK
+
+Check result in ``./manage.py dbshell``:
+
+::
+
+    db_name=# select make_sum(12, 15);
+     make_sum 
+    ----------
+           27
+    (1 row)
+
+Now, say, you want to change the function implementation so that it
+takes a custom type as argument:
+
+5) Edit your ``sql_config.py``:
+
+.. code:: python
+
+    # PostgreSQL example #2.
+    # Function and custom type.
+
+    from migrate_sql.config import SQLItem
+
+    sql_items = [
+        SQLItem(
+            'make_sum',  # name of the item
+            'create or replace function make_sum(a mynum, b mynum) returns mynum as $$ '
+            'begin return (a.num + b.num, 'result')::mynum; end; '
+            '$$ language plpgsql;',  # forward sql
+            reverse_sql='drop function make_sum(mynum, mynum);',  # sql for removal
+            # depends on `mynum` since takes it as argument. we won't be able to drop function
+            # without dropping `mynum` first.
+            dependencies=[('app_name', 'mynum')],
+        ),
+        SQLItem(
+            'mynum'   # name of the item
+            'create type mynum as (num int, name varchar(20));',  # forward sql
+            reverse_sql='drop type mynum;',  # sql for removal
+        ),
+    ]
+
+6) Generate migration ``./manage.py makemigrations``:
+
+::
+
+    Migrations for 'app_name':
+      0003_xxxx:
+        - Reverse alter SQL "make_sum"
+        - Create SQL "mynum"
+        - Alter SQL "make_sum"
+        - Alter SQL state "make_sum"
+
+You can take a look at the content this generated:
+
+.. code:: python
+
+    # -*- coding: utf-8 -*-
+    from __future__ import unicode_literals
+    from django.db import migrations, models
+    import migrate_sql.operations
+
+
+    class Migration(migrations.Migration):
+        dependencies = [
+            ('app_name', '0002_xxxx'),
+        ]
+        operations = [
+            migrate_sql.operations.ReverseAlterSQL(
+                name='make_sum',
+                sql='drop function make_sum(int, int);',
+                reverse_sql='create or replace function make_sum(a int, b int) returns int as $$ begin return a + b; end; $$ language plpgsql;',
+            ),
+            migrate_sql.operations.CreateSQL(
+                name='mynum',
+                sql='create type mynum as (num int, name varchar(20));',
+                reverse_sql='drop type mynum;',
+            ),
+            migrate_sql.operations.AlterSQL(
+                name='make_sum',
+                sql='create or replace function make_sum(a mynum, b mynum) returns mynum as $$ begin return (a.num + b.num, \'result\')::mynum; end; $$ language plpgsql;',
+                reverse_sql='drop function make_sum(mynum, mynum);',
+            ),
+            migrate_sql.operations.AlterSQLState(
+                name='make_sum',
+                add_dependencies=(('app_name', 'mynum'),),
+            ),
+        ]
+
+***NOTE:** Previous function is completely dropped before creation
+because definition of it changed. ``CREATE OR REPLACE`` would create
+another version of it, so ``DROP`` makes it clean.*
+
+***If you put ``replace=True`` as kwarg to an ``SQLItem`` definition, it
+will NOT drop + create it, but just rerun forward SQL, which is
+``CREATE OR REPLACE`` in this example.***
+
+7) Execute migration ``./manage.py migrate``:
+
+::
+
+    Operations to perform:
+      Apply all migrations: app_name
+    Running migrations:
+      Rendering model states... DONE
+      Applying brands.0003_xxxx... OK
+
+Check results:
+
+::
+
+    db_name=# select make_sum((5, 'a')::mynum, (3, 'b')::mynum);
+      make_sum  
+    ------------
+     (8,result)
+    (1 row)
+
+    db_name=# select make_sum(12, 15);
+    ERROR:  function make_sum(integer, integer) does not exist
+    LINE 1: select make_sum(12, 15);
+                   ^
+    HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
+
+For more examples see ``tests``.
+
+Feel free to `open new
+issues <https://github.com/klichukb/django-migrate-sql/issues>`__.
+
+.. |Build Status| image:: https://travis-ci.org/klichukb/django-migrate-sql.svg?branch=master
+   :target: https://travis-ci.org/klichukb/django-migrate-sql
+.. |codecov.io| image:: https://img.shields.io/codecov/c/github/klichukb/django-migrate-sql/master.svg
+   :target: https://codecov.io/github/klichukb/django-migrate-sql?branch=master

{django-migrate-sql-deux-0.4.0 → django_migrate_sql_deux-0.5.2}/django_migrate_sql_deux.egg-info/SOURCES.txt

@@ -1,4 +1,6 @@
+LICENSE
 README.rst
+pyproject.toml
 setup.cfg
 setup.py
 django_migrate_sql_deux.egg-info/PKG-INFO

django_migrate_sql_deux-0.5.2/migrate_sql/__init__.py

@@ -0,0 +1 @@
+__version__ = '0.5.2'

{django-migrate-sql-deux-0.4.0 → django_migrate_sql_deux-0.5.2}/migrate_sql/management/commands/makemigrations.py

@@ -8,7 +8,7 @@ import sys
 from django.core.management.commands.makemigrations import Command as MakeMigrationsCommand
 from django.db.migrations.loader import MigrationLoader
 from django.db.migrations import Migration
-from django.core.management.base import CommandError
+from django.core.management.base import CommandError, no_translations
 from django.db.migrations.questioner import InteractiveMigrationQuestioner
 from django.apps import apps
 from django.db.migrations.state import ProjectState
@@ -19,6 +19,7 @@ from migrate_sql.graph import build_current_graph
 
 class Command(MakeMigrationsCommand):
 
+    @no_translations
     def handle(self, *app_labels, **options):
 
         self.verbosity = options.get('verbosity')

django_migrate_sql_deux-0.5.2/pyproject.toml

@@ -0,0 +1,25 @@
+[tool.semantic_release]
+tag_format = "v{version}"
+version_variables = [ "migrate_sql/__init__.py:__version__" ]
+build_command = """
+pip install build
+python -m build
+"""
+
+[tool.semantic_release.changelog]
+mode = "update"
+exclude_commit_patterns = [
+  "chore.*",
+  "ci.*",
+  "Merge pull request .*",
+]
+
+[tool.semantic_release.changelog.environment]
+keep_trailing_newline = true
+
+[tool.semantic_release.branches.main]
+match = "main"
+
+[tool.semantic_release.branches.noop]
+match = "(?!main$)"
+prerelease = true

{django-migrate-sql-deux-0.4.0 → django_migrate_sql_deux-0.5.2}/setup.py

@@ -64,7 +64,6 @@ setup(
         'Natural Language :: English',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',
-        'Framework :: Django :: 2.0',
         'Framework :: Django :: 2.1',
         'Framework :: Django :: 2.2',
         'Framework :: Django :: 3.0',

{django-migrate-sql-deux-0.4.0 → django_migrate_sql_deux-0.5.2}/tests/test_project/settings.py

@@ -78,6 +78,7 @@ DATABASES = {
         'ENGINE': 'django.db.backends.postgresql_psycopg2',
         'NAME': 'migrate_sql_test_db',
         'USER': 'postgres',
+        'PASSWORD': 'postgres',
         'HOST': 'localhost',
         'PORT': 5432,
     }