Changes between Initial Version and Version 2 of Ticket #35410

Timestamp:

Apr 26, 2024, 2:01:28 PM (3 weeks ago)

Author:

Ebram Shehata

Comment:

Replying to Tim Graham:

You didn't provide the full traceback but I suspect the error comes from Department.objects.get_or_create(). I don't think Django is at fault. You could make the migrations in two steps, adding the default only after the Department table is created.

Oh, I just added the traceback.

• I think that is not the expected behavior when someone uses a callable as default parameter. I expect it to be used when the value was not provided and I'm trying to create an instance and of course not when I make migrations and that is working as expected when the target model is not a custom user model (inheriting from models.Model).

• I also think the work around of creating a data migration for creating the default instance is not actually convenient. Because I think the scenario could be:

Develop stuff. Create migration for the project and the a special migration for that default instance. After that we'll have to actually migrate the database so far to create that instance. Now develop the custom user profile and make migrations. Now we should be able to migrate database but no. Here's a problem that appeared with this scenario after adding the custom user model in this case:

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, profiles, sessions
Traceback (most recent call last):
  File "/SOME-DIR/blank_django/src/blanked/manage.py", line 22, in <module>
    main()
  File "/SOME-DIR/blank_django/src/blanked/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/base.py", line 413, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/base.py", line 459, in execute
    output = self.handle(*args, **options)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/base.py", line 107, in wrapper
    res = handle_func(*args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/core/management/commands/migrate.py", line 302, in handle
    pre_migrate_apps = pre_migrate_state.apps
                       ^^^^^^^^^^^^^^^^^^^^^^
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/utils/functional.py", line 47, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
                                         ^^^^^^^^^^^^^^^^^^^
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/db/migrations/state.py", line 566, in apps
    return StateApps(self.real_apps, self.models)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/SOME-DIR/blank_django/src/venv/lib/python3.11/site-packages/django/db/migrations/state.py", line 637, in __init__
    raise ValueError("\n".join(error.msg for error in errors))
ValueError: The field admin.LogEntry.user was declared with a lazy reference to 'profiles.userprofile', but app 'profiles' doesn't provide model 'userprofile'.

Overall about the scenario of having to create a data migration for that default instance, I think it's not convenient and it is not what's expected from a callable in default parameter. I think it should be behaving the same as with regular models, not having a special behavior if we're creating a custom user model.