Error in CharField with TextChoices and missing max_length parameter

[osamahasanone]

Dear Django Support Team,

I hope this message finds you well. I am writing to report an issue that I encountered while using Django, specifically with the CharField and TextChoices combination when specifying choices but not providing the max_length parameter.

Issue Description:

When attempting to add a field of type CharField with TextChoices defined but no max_length parameter in the model, running ./manage.py test USING SQLITE results in the following error:

django.db.utils.OperationalError: near "None": syntax error

Reproduction Steps:

1. Define a Django model with a CharField, TextChoices, and choices, but omit the max_length parameter:

from django.db import models
from django.utils.text import gettext_lazy as _

class DummyModel(models.Model):
    class DummyFieldChoices(models.TextChoices):
        OPTION1 = 'option1', _('Option 1')
        OPTION2 = 'option2', _('Option 2')
        OPTION3 = 'option3', _('Option 3')

    dummy_field = models.CharField(
        choices=DummyFieldChoices.choices,
        default=DummyFieldChoices.OPTION1,
    )

2. Run the Django test suite using WITH SQLITE (no issue with Postgres):

 ./manage.py test

Expected Result:
The Django test suite should run without any errors, and the model should be properly created in the database.

Actual Result:
The Django test suite encounters an OperationalError, with the error message being:

django.db.utils.OperationalError: near "None": syntax error

Example of Correct Usage:

from django.db import models
from django.utils.text import gettext_lazy as _

class DummyModel(models.Model):
    class DummyFieldChoices(models.TextChoices):
        OPTION1 = 'option1', _('Option 1')
        OPTION2 = 'option2', _('Option 2')
        OPTION3 = 'option3', _('Option 3')

    dummy_field = models.CharField(
        max_length=10,  # Specify the appropriate maximum length for your choices
        choices=DummyFieldChoices.choices,
        default=DummyFieldChoices.OPTION1,
    )

Additional Information:

Django Version: [4.2.3]
Python Version: [3.11.4]
Database: [Sqlite]

I hope this information helps you understand the issue I encountered. If you require any further details or assistance, please do not hesitate to reach out.

Thank you for your attention to this matter, and I look forward to your response.

[Tim Graham]

max_length is required on databases other than PostgreSQL. I believe the issue is that system checks (which would highlight this issue) are run after the test database is created (which fails due to missing max_length). I guess it's common to catch this sort of mistake using runserver before running test.

[Mariusz Felisiak]

I cannot reproduce your issue, when running test, makemigrations, or migrate, an error is raised in all cases:

$ ./manage.py test
Found 1 test(s).
Creating test database for alias 'default'...
Destroying test database for alias 'default'...
SystemCheckError: System check identified some issues:

ERRORS:
test_one.DummyModel.dummy_field: (fields.E120) CharFields must define a 'max_length' attribute.

System check identified 1 issue (0 silenced).

[Tim Graham]

Mariusz, did you perhaps remove max_length from a model without also updating the migration? I don't see how valid SQL could be producd with None interpolated as a ​max_length.

[Mariusz Felisiak]

Replying to Tim Graham:

Mariusz, did you perhaps remove max_length from a model without also updating the migration? I don't see how valid SQL could be producd with None interpolated as a ​max_length.

I missed that makemigrations didn't generate any migrations for me:

$ python manage.py makemigrations
SystemCheckError: System check identified some issues:

ERRORS:
test_one.DummyModel.dummy_field: (fields.E120) CharFields must define a 'max_length' attribute.

It seems that they used PostgreSQL to generate a migration and SQLite for tests.

[osamahasanone]

It seems that they used PostgreSQL to generate a migration and SQLite for tests.

That's correct.

We usually run tests against SQLite as it's faster.

[Tim Graham]

Offhand, I can't think of a reason why the test runner couldn't/shouldn't run checks before creating the test database. That would catch this and improve other situations where time is wasted on database setup only to fail at the check stage. Thoughts?

[Mariusz Felisiak]

Replying to Tim Graham:

Offhand, I can't think of a reason why the test runner couldn't/shouldn't run checks before creating the test database. That would catch this and improve other situations where time is wasted on database setup only to fail at the check stage. Thoughts?

Unfortunately, a database is required for some checks because database features can only be confirmed by introspecting the database, e.g. ​supports_json_field on SQLite.

[Tim Graham]

I suppose database setup could be split between CREATE DATABASE and table creation with checks run in between.