[Django] #34820: Change the properties of ForeignObject object, such as blank, null, and execute migrate to report an error
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
RelaxedDong |
Type: Bug | Status: new
Component: Database | Version: 4.2
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
… execute migrate to report an error
If the models.ForeignObject attribute is used, changing null or blank to
generate a new migration record will result in an error message when
executing the migrate again
```
File "/Users/donghao/test/test_migations/manage.py", line 22, in
<module>
execute_from_command_line(sys.argv)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/__init__.py", line 442, in
execute_from_command_line
utility.execute()
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/__init__.py", line 436, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/base.py", line 412, in run_from_argv
self.execute(*args, **cmd_options)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/base.py", line 458, in execute
output = self.handle(*args, **options)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/base.py", line 106, in wrapper
res = handle_func(*args, **kwargs)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/core/management/commands/migrate.py", line 356, in handle
post_migrate_state = executor.migrate(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/migrations/executor.py", line 135, in migrate
state = self._migrate_all_forwards(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/migrations/executor.py", line 167, in
_migrate_all_forwards
state = self.apply_migration(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/migrations/executor.py", line 252, in apply_migration
state = migration.apply(state, schema_editor)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/migrations/migration.py", line 132, in apply
operation.database_forwards(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/migrations/operations/fields.py", line 235, in
database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/base/schema.py", line 785, in alter_field
if not self._field_should_be_altered(old_field, new_field):
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/base/schema.py", line 1530, in
_field_should_be_altered
return self.quote_name(old_field.column) != self.quote_name(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/base/schema.py", line 204, in quote_name
return self.connection.ops.quote_name(name)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/mysql/operations.py", line 184, in quote_name
if name.startswith("`") and name.endswith("`"):
AttributeError: 'NoneType' object has no attribute 'startswith'
```
A pre judgment has been added here to avoid this issue
--
Ticket URL: <https://code.djangoproject.com/ticket/34820>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
New description:
Execute migrate to report an error
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:1>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Reporter: RelaxedDong | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by RelaxedDong:
Old description:
> Execute migrate to report an error
New description:
https://github.com/django/django/pull/17235
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:2>
Django
execute migrate to report an error
Reporter: RelaxedDong | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 4.2
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => needsinfo
* component: Database layer (models, ORM) => Migrations
* needs_tests: 0 => 1
Comment:
I'm not sure how to you reach a field without a `column` in migrations. I
don't think you've explained the issue in enough detail to confirm a bug
in Django, can you provide a sample project or test case that reproduces
the issue?
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:3>
Django
execute migrate to report an error
Reporter: puc_dong | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 4.2
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by puc_dong):
* component: Migrations => Database layer (models, ORM)
* needs_tests: 1 => 0
Old description:
> https://github.com/django/django/pull/17235
New description:
**models:**
{{{
# app1:
class Model1(models.Model):
name = models.CharField(max_length=50)
# app2:
class Model2(models.Model):
name = models.CharField(max_length=100, db_index=True)
clu_id = models.BigIntegerField()
scenes = models.ForeignObject(Model1,
from_fields=['clu_id'],
to_fields=['id'],
null=True,
related_name='model2_config',
on_delete=models.DO_NOTHING)
}}}
Successfully executed makemigrations&migrate for the first time. When I
add blank=True to the scenes field of Model2, and then execute
makemigrations and migrate to report an error
All migration files：
app1.0001_initial.py
{{{
class Migration(migrations.Migration):
initial = True
dependencies = [
]
operations = [
migrations.CreateModel(
name='Model1',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('name', models.CharField(max_length=50)),
],
),
]
{{{
class Migration(migrations.Migration):
initial = True
dependencies = [
('app_1', '0001_initial'),
]
operations = [
migrations.CreateModel(
name='Model2',
fields=[
('id', models.AutoField(auto_created=True,
primary_key=True, serialize=False, verbose_name='ID')),
('name', models.CharField(db_index=True, max_length=100)),
('clu_id', models.BigIntegerField()),
('scenes', models.ForeignObject(from_fields=['clu_id'],
null=True, on_delete=django.db.models.deletion.DO_NOTHING,
related_name='model2_config', to='app_1.model1', to_fields=['id'])),
],
),
]
}}}
app2.0002_alter_model2_scenes.py
{{{
class Migration(migrations.Migration):
dependencies = [
('app_1', '0001_initial'),
('app_2', '0001_initial'),
]
operations = [
migrations.AlterField(
model_name='model2',
name='scenes',
field=models.ForeignObject(blank=True,
from_fields=('clu_id',), null=True,
on_delete=django.db.models.deletion.DO_NOTHING,
related_name='model2_config', to='app_1.model1', to_fields=('id',)),
),
]
}}}
FIX: https://github.com/django/django/pull/17235
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:4>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: needsinfo =>
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:5>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Reporter: RelaxedDong | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by RelaxedDong):
Replying to [comment:3 Mariusz Felisiak]:
> I'm not sure how to you reach a field without a `column` in migrations.
I don't think you've explained the issue in enough detail to confirm a bug
in Django, can you provide a sample project or test case that reproduces
the issue?
I submitted my case code and process
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:6>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: new
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by puc_dong):
{{{
(simpleui) ☁ test_migations python manage.py makemigrations
System check identified some issues:
WARNINGS:
app_1.Model1: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App1Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
app_2.Model2: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App2Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
Migrations for 'app_1':
app_1/migrations/0001_initial.py
- Create model Model1
Migrations for 'app_2':
app_2/migrations/0001_initial.py
- Create model Model2
(simpleui) ☁ test_migations python manage.py migrate
System check identified some issues:
WARNINGS:
app_1.Model1: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App1Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
app_2.Model2: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App2Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
Operations to perform:
Apply all migrations: admin, app_1, app_2, auth, contenttypes, sessions
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying admin.0002_logentry_remove_auto_add... OK
Applying admin.0003_logentry_add_action_flag_choices... OK
Applying app_1.0001_initial... OK
Applying app_2.0001_initial... OK
Applying contenttypes.0002_remove_content_type_name... OK
Applying auth.0002_alter_permission_name_max_length... OK
Applying auth.0003_alter_user_email_max_length... OK
Applying auth.0004_alter_user_username_opts... OK
Applying auth.0005_alter_user_last_login_null... OK
Applying auth.0006_require_contenttypes_0002... OK
Applying auth.0007_alter_validators_add_error_messages... OK
Applying auth.0008_alter_user_username_max_length... OK
Applying auth.0009_alter_user_last_name_max_length... OK
Applying auth.0010_alter_group_name_max_length... OK
Applying auth.0011_update_proxy_permissions... OK
Applying auth.0012_alter_user_first_name_max_length... OK
Applying sessions.0001_initial... OK
**Add blank=True to the scenes field of Model2**
(simpleui) ☁ test_migations python manage.py makemigrations
System check identified some issues:
WARNINGS:
app_1.Model1: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App1Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
app_2.Model2: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App2Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
Migrations for 'app_2':
app_2/migrations/0002_alter_model2_scenes.py
- Alter field scenes on model2
(simpleui) ☁ test_migations python manage.py migrate
System check identified some issues:
WARNINGS:
app_1.Model1: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App1Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
app_2.Model2: (models.W042) Auto-created primary key used when not
defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the
App2Config.default_auto_field attribute to point to a subclass of
AutoField, e.g. 'django.db.models.BigAutoField'.
Operations to perform:
Apply all migrations: admin, app_1, app_2, auth, contenttypes, sessions
Running migrations:
Applying app_2.0002_alter_model2_scenes...Traceback (most recent call
last):
packages/django/db/backends/base/schema.py", line 1520, in
_field_should_be_altered
return self.quote_name(old_field.column) != self.quote_name(
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/base/schema.py", line 204, in quote_name
return self.connection.ops.quote_name(name)
File "/Users/donghao/.virtualenvs/simpleui/lib/python3.9/site-
packages/django/db/backends/mysql/operations.py", line 184, in quote_name
if name.startswith("`") and name.endswith("`"):
AttributeError: 'NoneType' object has no attribute 'startswith'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:7>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Database layer | Version: 4.2
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => invalid
Comment:
`ForeignObject` is an abstraction level, not a proper model field. You
should use `models.ForeignKey`. If you're having trouble understanding how
Django works, see TicketClosingReasons/UseSupportChannels for ways to get
help.
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:8>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by puc_dong):
Replying to [comment:8 Mariusz Felisiak]:
> `ForeignObject` is an abstraction level, not a proper model field. You
should use `models.ForeignKey`. If you're having trouble understanding how
Django works, see TicketClosingReasons/UseSupportChannels for ways to get
help.
We do not need to create a foreign key, we have used ForeignObject and
currently only need to perform queries. Should this field not be generated
in the migration record for the first time?
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:9>
Django
execute migrate to report an error
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
Replying to [comment:9 puc_dong]:
> Replying to [comment:8 Mariusz Felisiak]:
> > `ForeignObject` is an abstraction level, not a proper model field. You
should use `models.ForeignKey`. If you're having trouble understanding how
Django works, see TicketClosingReasons/UseSupportChannels for ways to get
help.
> We do not need to create a foreign key, we have used ForeignObject and
currently only need to perform queries. Should this field not be generated
in the migration record for the first time?
It seems that you have a niche use case. Trac is not a support channel,
you can try to discuss this with folks on the Django Forum.
--
Ticket URL: <https://code.djangoproject.com/ticket/34820#comment:10>