Opened 22 months ago

Last modified 22 months 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

Description (last modified by Gerben Morsink)

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"

Change History (7)

comment:1 Changed 22 months ago by Gerben Morsink

Description: modified (diff)

comment:2 Changed 22 months ago by Baptiste Mispelon

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.

comment:3 Changed 22 months ago by Gerben Morsink

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 Changed 22 months ago by Gerben Morsink

Description: modified (diff)

comment:5 Changed 22 months ago by Gerben Morsink

Description: modified (diff)

comment:6 Changed 22 months ago by Emre Yılmaz

in which database do you try this?

comment:7 Changed 22 months ago by Tim Graham

Component: Database layer (models, ORM)Migrations
Easy pickings: unset
Triage Stage: UnreviewedAccepted
Type: BugCleanup/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.

Note: See TracTickets for help on using tickets.
Back to Top