#29529: FilePathField path attribute gets resolved when running makemigrations.
-------------------------------------+-------------------------------------
Reporter: Sebastiaan Arendsen | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 2.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: migration, | Triage Stage:
filepathfield, makemigrations | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Hemanth V. Alluri):
* type: Uncategorized => New feature
* component: Migrations => Database layer (models, ORM)
Comment:
Replying to [comment:2 Sebastiaan Arendsen]:
> Replying to [comment:1 Hemanth V. Alluri]:
> > So, to clarify, what exactly is the bug/feature proposal/issue here?
The way I see it, you're supposed to use os.path.join() and LOCAL_FILE_DIR
to define a relative path. It's sort of like how we use BASE_DIR to define
relative paths in a lot of other places. Could you please clarify a bit
more as to what the issue is so as to make it easier to test and patch?
>
> LOCAL_FILE_DIR doesn't have to be the same on another machine, and in
this case it isn't the same on the production server. So the
os.path.join() will generate a different path on my local machine compared
to the server. When i ran ./manage.py makemigrations the Migration had the
path resolved "hardcoded" to my local path, which will not work when
applying that path on the production server. This will also happen when
using the BASE_DIR setting as the path of your FilePathField, seeing as
that's based on the location of your project folder, which will almost
always be on a different location.
>
> My suggestion would be to let makemigrations not resolve the path and
instead keep the os.path.join(), which I have now done manually. More
importantly would be to retain the LOCAL_FILE_DIR setting in the
migration.
Please look at this ticket: [https://code.djangoproject.com/ticket/6896] I
think that something like what sandychapman suggested about an extra flag
would be cool if the design decision was approved and if there were no
restrictions in the implementation for such a change to be made. But
that's up to the developers who have had more experience with the project
to decide, not me.
--
Ticket URL: <https://code.djangoproject.com/ticket/29529#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.6dfae1127e6c8fbbbca6ea005328e56e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
