TypeError: fromisoformat: argument must be str

Using Django Using the ORM
1

Hi,
I am facing the following TypeError, when running py manage.py migrate:

(venv) PS C:\Users\Name\codingprojects\CoderMatching\codermatching> py manage.py migrate  
System check identified some issues:

WARNINGS:
?: (mysql.W002) MariaDB Strict Mode is not set for database connection 'default'
        HINT: MariaDB's Strict Mode fixes many data integrity problems in MariaDB, such as data truncation upon insertion, by escalating warnings into errors. It is strongly recommended you activate it. See: https://docs.djangoproject.com/en/4.0/ref/databases/#mysql-sql-mode
Operations to perform:
  Apply all migrations: admin, auth, codermatch, contenttypes, sessions
Running migrations:
  Applying codermatch.0031_alter_ad_expirationtime_alter_ad_projectstartdate...Traceback (most recent call last):
  File "C:\Users\Name\codingprojects\CoderMatching\codermatching\manage.py", line 22, in <module>   
    main()
  File "C:\Users\Name\codingprojects\CoderMatching\codermatching\manage.py", line 18, in main       
    execute_from_command_line(sys.argv)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\__init__.py", line 425, in execute_from_command_line
    utility.execute()
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\__init__.py", line 419, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 373, in run_from_argv
    self.execute(*args, **cmd_options)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 417, in execute
    output = self.handle(*args, **options)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 90, in wrapped
    res = handle_func(*args, **kwargs)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\commands\migrate.py", line 253, in handle
    post_migrate_state = executor.migrate(
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 126, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 156, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 236, in apply_migration
    state = migration.apply(state, schema_editor)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\migration.py", line 125, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\operations\fields.py", line 225, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 618, in alter_field
    self._alter_field(model, old_field, new_field, old_type, new_type,
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 746, in _alter_field
    new_default = self.effective_default(new_field)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 334, in effective_default
    return field.get_db_prep_save(self._effective_default(field), self.connection)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\models\fields\__init__.py", line 839, in get_db_prep_save
    return self.get_db_prep_value(value, connection=connection, prepared=False)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\models\fields\__init__.py", line 1293, in get_db_prep_value
    value = self.get_prep_value(value)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\models\fields\__init__.py", line 1288, in get_prep_value
    return self.to_python(value)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\models\fields\__init__.py", line 1250, in to_python
    parsed = parse_date(value)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\utils\dateparse.py", line 76, in parse_date
    return datetime.date.fromisoformat(value)
TypeError: fromisoformat: argument must be str

The migration look like this:

(venv) PS C:\Users\Name\codingprojects\CoderMatching\codermatching> py manage.py makemigrations     
Migrations for 'codermatch':
  codermatch\migrations\0034_alter_ad_expirationtime.py
    - Alter field expirationTime on ad

models.py

class Ad(models.Model):
    expirationTime = models.DateTimeField('expiration time (of ad)', default=timezone.now() + datetime.timedelta(days=30))
    #... some other properties

settings.py

# Internationalization
# https://docs.djangoproject.com/en/4.0/topics/i18n/

LANGUAGE_CODE = 'de-de'

TIME_ZONE = 'Europe/Berlin'

USE_I18N = True

USE_TZ = True

I really donā€™t understand whatā€™s the issue here.
From my point of view the error message and the traceback arenā€™t helpful at allā€¦
I may only assume that this is caused by the expirationTime property in the Ad model, since itā€™s the only field mentioned, when running py manage.py makemigrations

Maybe someone has a suggestion?

2

Not the bug youā€™re experiencing, but this definition is probably not what you intend. timezone.now() will be evaluated once at import time, and a fixed date determined. So if you server stays up for 7 days, the expiry date will then be in 23 days time. If it stays up 31 days, the expiry date will be yesterday.

What you instead want is a callable default:

def in_30_days():
     return timezone.now() + timedelta(days=30)

class Ad(...):
     ... = models.DateTimeField(..., default=in_30_days)

Django will call this function when it creates a new instance, so each instance will get +30 days from the time you created this.

If you do this youā€™ll hit a different path, which should mean you donā€™t hit the particular bug youā€™re seeing.

Donā€™t ignore this! I was partially responsible for this warning making its way into Django.

1 Like
3

FYI you should also be seeing this check message that warns against this bug:

...Ad.expirationTime: (fields.W161) Fixed default value provided.
	HINT: It seems you set a fixed date / time / datetime value as default for this field. This may not be what you want. If you want to have the current date as default, use `django.utils.timezone.now`

Unless you put W161 in your SILENCED_SYSTEM_CHECKS

1 Like
4

Thank you for the quick reply Adam!

I thought that my definition of default=timezone.now() + datetime.timedelta(days=30) always creates an instance with the current time plus 30 days.
Honestly I was already wondering why itā€™s always altered when calling py manage.py makemigrations.

I just wanted to describe, why it works for me by showing you the different timestamps of objects in my database.
But along the way I realized, that even if I create objects in the shell they will all have the same expirationTime:

# objects already in database before:
>>> ads = Ad.objects.all() 
>>> for ad in ads:    ime    te)
...     print(ad.expirationTime)
... 
2022-02-11 07:30:44.036332+00:00
2022-02-11 07:30:44.036332+00:00
2022-02-11 07:30:44.036332+00:00
2022-02-11 07:30:44.036332+00:00
2022-02-11 07:30:44.036332+00:00
2022-02-14 06:37:07+00:00       
2022-02-20 07:11:04+00:00       
2022-02-22 06:47:54.104425+00:00
2022-02-22 07:23:24.417796+00:00
2022-02-22 07:27:41.230062+00:00
2022-02-22 08:02:22.279783+00:00
2022-02-22 08:02:22.279783+00:00
2022-02-23 07:21:50.931785+00:00
2022-02-23 08:56:08.720499+00:00
2022-02-23 08:56:08.720499+00:00
2022-02-23 08:56:08.720499+00:00
2022-02-24 12:58:31.475272+00:00
2022-02-24 13:10:20.509282+00:00
2022-02-24 13:13:55.324877+00:00
2022-02-24 13:22:04.863970+00:00
2022-02-27 06:52:29.463663+00:00
2022-02-27 06:52:29.463663+00:00
2022-02-27 07:09:34.572881+00:00
2022-02-27 07:10:25.415602+00:00
2022-02-28 23:32:35.943372+00:00
2022-02-28 23:32:35.943372+00:00
2022-02-28 23:36:01.314277+00:00
2022-02-28 23:36:25.137725+00:00
2022-02-28 23:37:33.127609+00:00
2022-02-28 23:38:53.338604+00:00
2022-02-28 23:38:53.338604+00:00
2022-02-28 23:38:53.338604+00:00
2022-03-01 00:13:07.788984+00:00
2022-03-01 00:13:07.788984+00:00
2022-03-01 07:00:56.857355+00:00
2022-03-01 07:07:38.445522+00:00
2022-03-01 08:28:08.078065+00:00
2022-03-01 08:28:38.855122+00:00
2022-03-01 08:28:38.855122+00:00
2022-03-01 14:52:20.143607+00:00
2022-03-01 14:52:20.143607+00:00
2022-03-01 15:51:17.024533+00:00
2022-03-02 17:03:12.778584+00:00
2022-03-03 07:01:54.826885+00:00
2022-03-03 07:01:54.826885+00:00
2022-03-03 07:01:54+00:00
2022-03-03 10:43:28.610037+00:00
2022-03-03 10:43:28.610037+00:00
2022-03-03 10:51:08.047444+00:00
2022-03-03 11:33:02.518281+00:00
2022-03-03 11:33:02.518281+00:00
2022-03-03 11:42:45.651000+00:00
2022-03-03 11:42:45.651000+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-03 13:02:57.146329+00:00
2022-03-04 06:22:43.667378+00:00
2022-03-04 07:07:39.222599+00:00
2022-03-04 07:11:18.155299+00:00
2022-03-04 07:17:55.524739+00:00
2022-03-04 07:20:45.652661+00:00
2022-03-04 11:29:31.495141+00:00
2022-03-04 11:29:31.495141+00:00

# add new object to the database
>>> newAd = Ad(projectTitle='testexpirationTimestamp')
>>> newAd.save()
>>> print(newAd.expirationTime)  
2022-03-11 14:41:13.813310+00:00

#add another new object to the database (few minutes lates)
>>> newAd = Ad(projectTitle='testexpirationTimestamp2')
>>> newAd.save()
>>> print(newAd.expirationTime)  
2022-03-11 14:41:13.813310+00:00

So in this case the expirationTime seems to be based on the time when the shell was started, right?
Since all objects which I create in the same shell instance will have the same expirationTime.

Thank you very much for pointing this out!:pray:

I havenā€™t deployed an app which is based on my own ideas and logic.
But from based on your statement I understand the following:

Once I deploy the app the server would behave similar to the django shell in this case.
It would save the time at which I deployed the app and alter the expirationTime property once at that time.
So that every Ad object (created at any time after deployment) would always have this one expirationTime, right?

If I make the check, I donā€™t see warnings:

(venv) PS C:\Users\Name\codingprojects\CoderMatching\codermatching> py manage.py check
System check identified no issues (0 silenced).

Thank you for pointing this out, too!
I didnā€™t consider this to be an issue.
Because I donā€™t remeber a point in the development, where this did not appear.
So I was assuming that this is just normal.
Besides I am not even using MariaDB.
I am working on a MySQL database.
But itā€™s the first time for me building my own web app (without just following a tutorial).
And itā€™s especially the first time for me using a database which is not SQLite (Because people on the internet seem to agree, that you shouldnā€™t use SQLite for apps where users can create, update or delete data.

5

Yes it is defined at import time. So once per Python process.

Yes, although your web server may also restart occasionally in production.

Ensure youā€™re on the latest django and you donā€™t have that in your settings. I donā€™t know which django version added this warning off the top of my head.

This is called ā€œwarning fatigueā€. Ignore warnings long enough and your brain tunes them out. But someone put the message there for a reason :slight_smile:

On most linux distributions MySQL is an alias for MariaDB. You may be using MariaDB without even know it. Iā€™d be surprised if Djangoā€™s detection logic was wrong.

Itā€™s actually fine to use SQLite up to a reasonable level of traffic: Appropriate Uses For SQLite

You can get streaming backups with Litestream: https://litestream.io/

Iā€™ve been meaning to play with SQLite in production myself, since finding out about Litestream.

1 Like
6

Iā€™ve implemented it like this now:

class Ad(models.Model):
    ...
    def in30Days():
        return timezone.now() + datetime.timedelta(days=30)
    ...
    expirationTime = models.DateTimeField('expiration time (of ad)', default=in30Days)

Every time I create a new Ad object now, it really has the current time.

Iā€™ve solved the mysql.W002 by adding OPTIONS to my DATABASES in settings.py (as recommended in the error message:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'codermatchingdb',
        'USER': 'root',
        'PASSWORD': 'secretšŸ˜‰',
        'HOST': '127.0.0.1',
        'PORT': '',
        'OPTIONS': {
            'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
        }
    }
}

My settings.py has:

Generated by 'django-admin startproject' using Django 4.0.1.

and on the other hand (from my venv):

>>> import django
>>> django.VERSION
(4, 0, 1, 'final', 0)

Thank you! Iā€™ll keep that in mind :slight_smile:

Thank you for the hint.
Maybe Iā€™ll consider switching to SQLite, if I am facing more issues which hinder the actual coding.

TypeError still an issue

However I am still facing the TypeError: fromisoformat: argument must be str in the Running migrations when calling py manage.py migrate (see above).
When I google for it I always only find issues, which where solved with the callable default.

7

I think you may need to edit your historical migrations then. Itā€™s probably being caused by one of the defaults you placed in an old migration. It should be safe to edit the default field being set in old migrations, since you now have a correct default being set in a new migration.

2 Likes
8

Thank you.
Inspired by the latest migration I amended the historical migrations from something likeā€¦

import datetime
from django.db import migrations, models
from django.utils.timezone import utc


class Migration(migrations.Migration):
    ...
    operations = [
        migrations.AlterField(
            model_name='ad',
            name='expirationTime',
            # note that the following DateTimeField has a fixed time as default
            field=models.DateTimeField(default=datetime.datetime(2022, 3, 12, 7, 56, 7, 340439, tzinfo=utc), verbose_name='expiration time (of ad)'),
        ),
    ]

to something likeā€¦

import codermatch.models
from django.db import migrations, models


class Migration(migrations.Migration):
    ...
    operations = [
        migrations.AlterField(
            model_name='ad',
            name='expirationTime',
            # note that the following DateTimeField has a callable function which provides a "dynamic" time - as recommended above by Adam 
            field=models.DateTimeField(default=codermatch.models.Ad.in30Days, verbose_name='expiration time (of ad)'),
        ),
    ]

Besides I cleared up the migrations by deleting several trivial ones - for example those ones which always only altered the expirationTime to the current time.

new error: django.db.utils.DataError: (1265, ā€œData truncated for column ā€˜projectStartDateā€™ at row 50ā€)

Now I have a new error when calling py manage.py migrate:

(venv) PS C:\Users\Name\codingprojects\CoderMatching\codermatching> py manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, codermatch, contenttypes, sessions
Running migrations:
  Applying codermatch.0034_alter_ad_expirationtime... OK
  Applying codermatch.0042_alter_ad_expirationtime... OK
  Applying codermatch.0043_alter_ad_projectstartdate...Traceback (most recent call last):
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\mysql\base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\cursors.py", line 206, in execute
    res = self._query(query)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\cursors.py", line 319, in _query
    db.query(q)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\connections.py", line 254, in query
    _mysql.connection.query(self, query)
MySQLdb._exceptions.DataError: (1265, "Data truncated for column 'projectStartDate' at row 50")

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\Users\Name\codingprojects\CoderMatching\codermatching\manage.py", line 22, in <module>
    main()
  File "C:\Users\Name\codingprojects\CoderMatching\codermatching\manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\__init__.py", line 425, in execute_from_command_line
    utility.execute()
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\__init__.py", line 419, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 373, in run_from_argv
    self.execute(*args, **cmd_options)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 417, in execute
    output = self.handle(*args, **options)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\base.py", line 90, in wrapped
    res = handle_func(*args, **kwargs)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\core\management\commands\migrate.py", line 253, in handle
    post_migrate_state = executor.migrate(
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 126, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 156, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\executor.py", line 236, in apply_migration
    state = migration.apply(state, schema_editor)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\migration.py", line 125, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\migrations\operations\fields.py", line 225, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 618, in alter_field
    self._alter_field(model, old_field, new_field, old_type, new_type,
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 775, in _alter_field
    self.execute(
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\base\schema.py", line 151, in execute
    cursor.execute(sql, params)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 99, in execute
    return super().execute(sql, params)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 67, in execute
    return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 76, in _execute_with_wrappers
    return executor(sql, params, many, context)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\utils.py", line 90, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\utils.py", line 85, in _execute
    return self.cursor.execute(sql, params)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\django\db\backends\mysql\base.py", line 73, in execute
    return self.cursor.execute(query, args)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\cursors.py", line 206, in execute
    res = self._query(query)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\cursors.py", line 319, in _query
    db.query(q)
  File "C:\Users\Name\codingprojects\CoderMatching\venv\lib\site-packages\MySQLdb\connections.py", line 254, in query
    _mysql.connection.query(self, query)
django.db.utils.DataError: (1265, "Data truncated for column 'projectStartDate' at row 50")

Since Iā€™ve already marked a solution for the issue of the thread, the forum adviced me to open a new thread.
Shall I open a new thread or does this still fit in here?

9

Itā€™s fine here.

What is 0043_alter_ad_projectstartdate doing to projectStartDate?

Truncating data means removing characters that have been stored, e.g. if you had a varchar(8) storing ā€œabcdabcdā€ then tried to migrate it to varchar(6), the last two characters would be truncated, so MySQL prevents that.

Can you perhaps figure out why that migration tries to do something so unsafe, and modify eithre the stored data or the migrration to prevent the error?

1 Like
10

This is what it does:

from django.db import migrations, models


class Migration(migrations.Migration):

    dependencies = [
        ('codermatch', '0042_alter_ad_expirationtime'),
    ]

    operations = [
        migrations.AlterField(
            model_name='ad',
            name='projectStartDate',
            field=models.DateField(blank=True, verbose_name='project started (date)'),
        ),
    ]

This is how projectStartDate looks:

class Ad(models.Model):
    ...
    projectStartDate = models.DateField('project started (date)', blank=True)

After deleting several rows in the database, Django now complains about the row 49:

django.db.utils.DataError: (1265, "Data truncated for column 'projectStartDate' at row 49")

And every time I delete a line it complains about another one.

Iā€™ve exported the database from phpmyadmin.
And Iā€™ve deleted the lines in the beginning. So that the line numbers fit the rows.
So row 49 is the one with the NULL value:

grafik
grafik1361Ɨ137 15.6 KB

Therefore I thought that the NULL value is a problem.

add null=True

Iā€™ve amended the projectStartDate to have null=True:

class Ad(models.Model):
    ...
    projectStartDate = models.DateField('project started (date)', blank=True, null=True)

py manage.py makemigrations results in a new migration:

...
class Migration(migrations.Migration):
...
    operations = [
        migrations.AlterField(
            model_name='ad',
            name='projectStartDate',
            field=models.DateField(blank=True, verbose_name='project started (date)'),
        ),
    ]

delete row 49 (including NULL value)

Then Iā€™ve deleted the object in row 49 from my phpmyadmin.

py manage.py migrate then results in:
django.db.utils.DataError: (1265, "Data truncated for column 'projectStartDate' at row 59")
After deletion of row 49, row 59 is the first one having a NULL for projectStartDate.

If I change the NULL value of row 59 (id 67) to a date (using the calender widget in phpmyadmin) and then running py manage.py migrate again, the output says:
django.db.utils.DataError: (1265, "Data truncated for column 'projectStartDate' at row 62")

grafik
grafik1329Ɨ328 30.5 KB

As you may presume, row 62 then is the first one in the database with a NULL in projectStartDate.
If I change the value of row 59 back to NULL, the error occurs there again.

Therefore I assume that Django (or MySQL) has a problem with the NULL values now.
But I donā€™t understand why.
:thinking:Since Iā€™ve just defined null=True, which should make NULL values in the database possible - in my understandingā€¦

By the way

In this case itā€™s actually not a huge problem.
If I just create a new database (which I can easily do, since I donā€™t have important data in the database so far) and connect my Django project to this one, I donā€™t have this issue anymore.

The reason why I am trying to investigate this further is:
I think itā€™s good to learn how to solve those kind of issues while I am not working with sensitive or important data in a deployed project.
But rather now while I itā€™s not too much of a problem (actually).
Do you think itā€™s good to do it and learn it like this?
Or do you think that itā€™s better to focus on the actual development of the application and solve problems (which might be considered trivial) lateršŸ˜…?