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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
