Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#29808 closed Bug (fixed)

Applied migration detection may fail when using a case-insensitive collation

Reported by: Elaci0 Owned by: Hasan Ramezani
Component: Migrations Version: dev
Severity: Normal Keywords: migration fake-initial case sensitive
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

Hello,
I'm using this guide https://datascience.blog.wzb.eu/2017/03/21/using-django-with-an-existinglegacy-database for my studies with camelCasing together with Django (yes, I'm still trying to keep the naming convention we have inside our DB, also for the model's names)

Now, I'm really new to Django and I don't know if it's intended but this part of code inside django/db/migrations/executor.py' is doing case sensitive comparison to check if a column is already present in a database

column_names = [
    column.name for column in
    self.connection.introspection.get_table_description(self.connection.cursor(), table)
]
if field.column not in column_names:
    return False, project_state

so if my migration file contains something like this

        migrations.AddField(
            model_name='city',
            name='countrycode',
            field=models.ForeignKey(db_column='countryCode', on_delete=django.db.models.deletion.CASCADE, to='my_DB.country'),

and I run python3 manage.py migrate --database my_DB --fake-initial my_first_app

it fires an error saying that that table already exists
django.db.utils.OperationalError: (1050, "Table 'city' already exists")

If I run python3 manage.py migrate --database my_DB --fake my_first_app it correctly fakes my_first_app
The my_DB collation is case insensitive, while MySql is running with the ' --lower-case-table-names=0' option

Change History (9)

comment:1 by Tim Graham, 5 years ago

Description: modified (diff)
Summary: column checks inside "executor.py" is not case sensitiveApplied migration detection may fail when using a case-insensitive collation
Triage Stage: UnreviewedAccepted
Type: UncategorizedBug

comment:2 by Hasan Ramezani, 4 years ago

Has patch: set
Owner: changed from nobody to Hasan Ramezani
Status: newassigned

Not sure about the solution.
PR just created for proposing the solution.

comment:3 by Mariusz Felisiak, 4 years ago

Needs tests: set
Patch needs improvement: set
Version: 2.1master

comment:4 by Hasan Ramezani, 4 years ago

Needs tests: unset
Patch needs improvement: unset

comment:5 by Simon Charette, 4 years ago

Patch needs improvement: set

Left a few comments for improvements.

comment:6 by Hasan Ramezani, 4 years ago

Patch needs improvement: unset

comment:7 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

In d0c86a1d:

Refs #29808 -- Optimized MigrationExecutor.detect_soft_applied().

Use set() for iterables used only for containment checks. Simplify
column checks O(n) instead of O(2n).

Thanks Simon Charette for an idea.

comment:8 by Mariusz Felisiak <felisiak.mariusz@…>, 4 years ago

Resolution: fixed
Status: assignedclosed

In 530dd19:

Fixed #29808 -- Fixed initial migration detection when identifiers are case-insensitive.

Thanks Simon Charette for the review.

comment:9 by GitHub <noreply@…>, 4 years ago

In 4527d5db:

Refs #29808 -- Fixed MigrateTests.test_migrate_fake_initial_case_insensitive() crash on Oracle.

Note: See TracTickets for help on using tickets.
Back to Top