El martes, 16 de mayo de 2017, 5:41:20 (UTC-4), James Schneider escribió:
James. Thank you a lot for your guidance ...
> TBH, you may want to rethink your approach to this problem. If you are
> generating paths relative to a variable, then simple concatenate the given
> path and variable accordingly. Keep in mind that the generated value is
> what is being stored, so any illusion of a dynamic path would be lost.
>
>
I want that. But if you do that, the migration being produced will:
* Or Be not possible to create, because the migration mechanism will not
be able to serialize an expression as simple as `settings.A_SETTING`.
* Or Will have the value of your development environment
> If it were me, I'd investigate only keeping the short path (to keep the
> original value as long as possible), and adding the variable prefix after
> the object is retrieved later, but that may not be possible. It would make
> it easy to switch all of your paths to another section of the file system
> by changing a single setting. Otherwise you'll be left with modifying the
> existing values in the DB in the event of a location change, which can get
> messy quickly.
>
>
Precisely this is the reason of why I'm in such a mess.
My objective is to "...make it easy to switch all of your paths to another
section of the file system by changing a single setting".
That is why I tried to simply assign a setting variable to the path
argument of a FilePathField constructor. But due the migration problem, is
not as simple as it should be.
It is not so much about the prefixing. In fact, I must correct my words:
I'm not trying to prefix anything as you can see in my code example: I just
want to assign a settings variable as the value of the path argument of the
FilePathField constructor. In other words,
...
I want to write:
models.FilePathField(path=settings.A_SETTING)
But I can't because migration don't understand that. So I had to write:
models.FilePathField(path=StringSettingsReference('A_SETTING'))
where StringSettingsReference is my custom class.
I got inspiration for this solution from:
*
http://jakzaprogramowac.pl/pytanie/20808,django-migrations-and-customizable-reusable-apps
*
https://docs.djangoproject.com/en/1.11/topics/migrations/#adding-a-deconstruct-method
Thank you a lot for your help.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/fe37d399-3789-4fe5-8f56-534218b34b80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
