Example:
In settings.py:
{{{
UPLOAD_ROOT = os.path.normpath(os.path.join(PROJECT_DIR, '..', '..',
'uploads'))
UPLOAD_URL = '/content/'
}}}
In the model:
{{{
upload_storage = FileSystemStorage(location=UPLOAD_ROOT,
base_url=UPLOAD_URL)
...
class Thingie(models.Model):
image = models.ImageField(upload_to='/%Y/%m/%d',
storage=upload_storage, null=True, default=None)
}}}
The migrations will consider Thingie to have changed from dev to
deployment based on the change of 'upload_storage'.
--
Ticket URL: <https://code.djangoproject.com/ticket/24648>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: andrewgodwin (added)
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
One idea (not sure if it would cause problems) is to modify the migration
file to replace the literal value `'/content/'` with a reference to the
setting, `settings.UPLOAD_URL`. If so, we could document this.
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:1>
* cc: MarkusH (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:2>
Comment (by timgraham):
[https://github.com/django/django/pull/4605 PR] has been proposed to allow
the `FileField` `storage` argument to take a callable in order to work
around this issue. It doesn't seem ideal to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:3>
* cc: ben@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:4>
Comment (by MarkusH):
For the time being and while I'm thinking of a proper solution, can you
try this, please.
{{{#!python
from django.db.migrations.writer import SettingsReference
upload_root_reference = SettingsReference(UPLOAD_ROOT, 'UPLOAD_ROOT')
upload_storage = FileSystemStorage(location=upload_root_reference,
base_url=upload_root_reference)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:5>
Comment (by MarkusH):
I may point out that above is not a public API but is used by e.g. the
swappable user model.
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:6>
Comment (by Tai Lee):
We've encountered issues with migrations storing serialized settings at
the time the migration was created. We've always fixed them in our
projects and suggested to 3rd party projects that they simple edit the
resulting migration to import and use the setting directly instead of its
serialized value. No need for callables.
I suppose something like `SettingsReference` might allow the auto
migration to detect and properly reference the setting automatically, but
it seems like an *extremely* easy mistake to forget to do this in advance
and to end up with serialized migrations where the fix still requires
manually editing the migration, at which point the use of
`SettingsReference` is redundant.
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:7>
* cc: Alex (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/24648#comment:8>