To any future readers, the real answer is that connections are deeply baked into how Django migrations operate. Things as seemingly simple as `can_migrate_model` require a connection. The other problems pointed out by Jason are easily patched, but the schema_editor (and all of the migration operations in migrations/operations which rely on the schema_editor) totally break without a connection.
I think it could be done, but it isn't an easy patch. On Saturday, 11 December 2021 at 07:59:32 UTC-8 Jason wrote: > > https://github.com/django/django/blob/main/django/db/migrations/loader.py#L20-L40 > > the comment in the migration loader class probably explains your > question. also, look at `collect_sql` at the bottom, and how its used at > the end of sqlmigrate. specifically, it uses schema editor ( > https://docs.djangoproject.com/en/3.2/ref/schema-editor/#module-django.db.backends.base.schema) > > as a context manager to have the connection turn migration nodes to SQL. > > > > > > On Friday, December 10, 2021 at 12:06:21 PM UTC-5 > [email protected] wrote: > >> Build graph has a specific separate path for `if self.connection is >> None:`, so that shouldn't be an issue? >> As far as atomicity, what if, in a case where no connection is found, it >> could just prompt: "No database connection found. Do you want your >> migration to be atomic? (y/N)" >> On Thursday, 9 December 2021 at 05:01:31 UTC-8 Jason wrote: >> >>> It uses db connection in two places: >>> >>> building the migration graph >>> <https://github.com/django/django/blob/eba9a9b7f72995206af867600d6685b5405f172a/django/db/migrations/loader.py#L210-L215> >>> in >>> order to load previous applied migrations and transaction begin/end >>> wrapping >>> <https://github.com/django/django/blob/main/django/core/management/commands/sqlmigrate.py#L58-L60> >>> >>> This makes sense, because you can have N unapplied migrations between >>> the db and your migrations history package. >>> >>> >>> >>> On Tuesday, December 7, 2021 at 7:46:42 PM UTC-5 >>> [email protected] wrote: >>> >>>> Wondering why sqlmigrate needs a connection to an existing database. >>>> >>>> I understand that for certain commands, it needs the database to >>>> generate the migration. But for most (basic) commands, no connection is >>>> really needed. >>>> >>>> For example, I created a test project >>>> <https://github.com/ShmuelTreiger/test-django-project/tree/master/testproject/migrations>and >>>> >>>> generated migration files. Without ever running the `migrate` command, I >>>> was able to use `sqlmigrate` perfectly well on all migrations, save the >>>> last, which drops a `unique_together`. >>>> >>>> I'm sure there are other commands which actually need a database >>>> connection (though I haven't found them yet). Seems to me sqlmigrate could >>>> be rewritten along the lines of: >>>> >>>> - Try to generate sql from migration file >>>> - If it hits a command it needs the database, attempt to connect >>>> >>>> Or else: >>>> >>>> - If no connection, check if migration file needs connection to >>>> database >>>> >>>> Is there something I'm unaware of? >>>> >>>> >>>> This email may contain confidential material; unintended recipients >>>> must not disseminate, use, or act upon any information in it. If you >>>> received this email in error, please contact the sender and permanently >>>> delete the email. >>> >>> -- This email may contain confidential material; unintended recipients must not disseminate, use, or act upon any information in it. If you received this email in error, please contact the sender and permanently delete the email. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7bdf8126-6f75-4569-88b5-12856bf565c5n%40googlegroups.com.
