Modify the model class field *_image_url and just remove _url.
Fields are defined in the model class
*_image_url = models.ImageField()
Pycharm sees the fields appearing in the database:
When querying the database using the model class, an error is reported:
django.db.utils.OperationalError: (1054, "Unknown column 'tb_sku.*_image_url' in 'field list'")
1. The query database tb_sku table does have the *_image_url field, which is exactly the same.
Query the model class, the model class field name is *_image_url, and the type is ImageField.
2. After thinking to no avail, decided to try to modify the field name, remove _url, and re-migrate the model class.
The migration file is created successfully, the migration fails, and an error is reported:
|pymysql.err.OperationalError: (1054, “Unknown column ‘*_image_url’ in ‘tb_sku'”)|
|django.db.utils.OperationalError: (1054, “Unknown column ‘*_image_url’ in ‘tb_sku'”)|
3. Comment out the *_image_url in the initial migration file to
create the migration file failed. Error:
|pymysql.err.OperationalError:(1060, “Duplicate column name ‘*_image'”)|
|django.db.utils.OperationalError: (1060, “Duplicate column name ‘*_image'”)|
4. Combining the above two errors, there is no *_image_url field in the database, and the *_image field is repeatedly defined. Explain that the database field *_image_url I saw through PyCharm has its real name *_image.
Then prove the conjecture, not insist on database migration, directly confirm that the field of the model class has been changed to *_image, restart the service again, send the request, and respond successfully!
5. Summary: Don’t define model class fields with _url at the end. When the database is migrated, this tail will be ignored directly. The real field name created in the database does not have this tail. Even if you see _url in this field in PyCharm, it is actually deceiving your eyes.
6. What is interesting is that when I tried to reproduce the problem in order to write this blog, I found that, but I commented out the _url field in the initial migration file, and the field in the model class retained _url, the database migration was successful. I went to check the database (in PyCharm) and found that the value is *_image, and the value is *_image_url. In other words, due to the newly added *_image_url field, the original *_image_url has been beaten back to the original *_image.
- [Solved] MYSQL add foreign key error: Referencing column ‘xx’ and referenced column ‘xx’ in foreign key constraint ‘xxx’ are incompatible.
- [Solved] Search with xadmin_ Related field got invalid lookup: icontains
- [Solved] Django use search_fields error (in get_lookup_constraint)
- How to Solve Django Error: No such column: xxx
- Solution of data truncated for column ‘xxx’ in MySQL
- Django auth.User.groups: (fields.E304) Reverse accessor for User.groups clashes with reverse
- [Solved] Django REST Framwork Use HyperlinkedModelSerializer Error: `HyperlinkedIdentityField` requires the request in the serializer context
- [Solved] DjangoORM Run python manage.py makemigrations Error: no changes detected
- [Solved] The length of the data truncation done by springboothinesdata for the column.
- Example of Django model unique together