Opened 9 years ago
Last modified 9 years ago
#25866 new Cleanup/optimization
Django migrations not picking up max_length change on FileField
Reported by: | Gerben Morsink | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.7 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Pull Requests: | How to create a pull request | ||
Description (last modified by ) ¶
I have subclassed a FileField (call it S3storage) which first had no max_length
Now I changed max_length to 1000. Then running ./manage.py makemigrations it does not seems to be picked up.
The only thing I did was:
class S3FileField(models.FileField): def __init__(self, *args, **kwargs): super(S3PrivateFileField, self).__init__(*args, **kwargs) self.storage.default_acl = "private"
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (7)
comment:1 by , 9 years ago
Description: | modified (diff) |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Ah, sorry! It works like I posted. But I wanted to do:
class S3PrivateFileField(models.FileField): def __init__(self, *args, **kwargs): if not kwargs.get('max_length',None): kwargs.update({'max_length':1000}) super(S3PrivateFileField, self).__init__(*args, **kwargs) self.storage.default_acl = "private"
comment:4 by , 9 years ago
Description: | modified (diff) |
---|
comment:5 by , 9 years ago
Description: | modified (diff) |
---|
comment:7 by , 9 years ago
Component: | Database layer (models, ORM) → Migrations |
---|---|
Easy pickings: | unset |
Triage Stage: | Unreviewed → Accepted |
Type: | Bug → Cleanup/optimization |
I can reproduce the issue -- the choice of database shouldn't matter as it's an issue with the autodetector. I'm not sure how/if it can be fixed though. Any fields that use the default max_length
won't have that data written to the migration file, so if the default is changed, Django has no way of knowing about this. We might have to document the limitation. I thought that adding an explicit max_length
to any fields in existing migration files would be a workaround, but unless I made an error in my testing, this doesn't work although I didn't track down the reason why.
Hi,
What you're describing seems to work for me (Django detects the change and writes a migration).
Could you show the full code of your model and custom field?
Thanks.