Add ability to store only relative paths in a FilePathField

[graham.carlyle@…]

Add an extra option to FilePathField to cause it to only save a relative path, say called "store_relative".

Having an absolute path stored makes it harder to move data between machines that are set up differently (say development and production). In this circumstance you would typically set the path parameter from the settings file.

The "store_relative" argument could default to False to keep the current behaviour by default.

[Greg Brown]

The only downside of changing this would be that your data would become broken whenever you changed the path option. I'd still be in favour of making it an option though.

[Kyle Dodson]

Adds a "RelativeFilePathField"

[Kyle Dodson]

I've added the above patch just to get something out there, but I'm marking "Patch needs improvement" because:

1. The os.path.relpath() function is only available in Python 2.6 and later.
2. I think the documentation needs work (I'm new around here and still learning).

There's a catch to this field as gregplaysguitar points out above, but depending on the situation this may work out OK. For instance, if it becomes necessary to move a folder on the server the absolute paths stored by FilePathField will become broken. However, if the paths are relative so long as the final destination keeps the same content/structure nothing in the database should have to change. In addition, this reduces the amount of (redundant) path data stored in the database.

[Gabriel Grant]

I can see there being merit to storing absolute paths in some cases, but having the option for relative paths seems sensible. In any case, I ran into this recently while migrating data and wrote a couple helper management commands to fix the absolute FilePathField values after migration (useful in conjunction with dumpdata/loaddata). For others running into this, here it is: ​https://github.com/gabrielgrant/django-filepathfield-migrator

[FunkyBob]

On top of all the above, using relative paths also makes it easier if you want to present a URL to the file ... you no longer need to strip the common prefix.

[Carl Meyer]

I buy that there are reasons why someone might prefer to store relative paths instead of absolute paths. But ultimately, this is an internal implementation choice; providing options for everything just makes Django more confusing to use. This added option in the documentation would be one more thing any new user picking up FilePathField for the first time would have to understand and make a decision about. For those who really want relative paths, the code in the patch for RelativeFilePathField can live outside Django core and work just fine.

[sandychapman@…]

The only problem being this being closed is that wiki link posted in the comments is broken. So now, for those who come to this page when looking for a relative path solution (without using just a plain old CharField or TextField which will have no path validation or drop-down selection box on the admin page) they will have nothing. TBH, relative paths are much more useful than absolute paths as, like others have noted, the development box is not usually (and shouldn't be) the same as the deployment box. I could run a VM on my dev box which has the same paths as my deployment box, but I shouldn't have to. This requires scripts to be written to modify every row in the db, when something as simple as a flag could be added to the FilePathField which tells it to solely store the relative path.

E.g.
Instead of

file_source = models.FilePathField(path='C:\workspace/path/to/filestore/', recursive=True)

you could have

file_source = models.FilePathField(path='C:\workspace/path/to/filestore/', recursive=True, store_relative=True)

Just have this flag default to False and you remove the justification you've given for closing this issue as won't fix. Users setting up databases won't be anymore confused about having an extra option in the model construction as they already are with having that option missing. They'll be wondering, "how do I make this relative path?" then spend 10 minutes Googling for a solution only to find that the Django devs deemed it too confusing for them. In any case, these people are likely developers who should know what they're doing anyway.

Sorry for the rant, I just completely disagree with why this issue was closed and think the feature detailed would be a nice improvement.

[chris.case@…]

I don't understand the fear of adding an option. FilePathField already has several, and they already have defaults. A new user doesn't have to make a decision if the core development team's already made it for him. That's the point of providing sane defaults, something django's extremely good at.

One of the things I love about django is it's "Batteries Included" approach. In this regard, the ability to store relative paths should be a no-brainer. What's more (maybe I'm just special, but...) I've never once wanted to use a FileFieldPath with an absolute path. All my use cases have required it to be relative (since I'm typically pre-populating the database with fixtures, and deploying on a different machine than I develop on). It's finally annoyed me enough to come comment on this ticket.

Personally, I don't think you give your users enough credit. "relative paths" aren't a crazy concept that only the Computer Elite can fathom... it's a basic consideration that crops up often in web development. Grab a random django newbie, and ask them if you want; I'll bet you 20 bucks that they don't stumble on this.

[secret24@…]

I think an option for storing relative paths would be a good thing... I even would set it to default behaviour... If i want to save a location of a file into database, i would still like to be able to take my project to another server without breaking all those paths....

[Alex Hayes]

Replying to carljm:

I buy that there are reasons why someone might prefer to store relative paths instead of absolute paths. But ultimately, this is an internal implementation choice; providing options for everything just makes Django more confusing to use. This added option in the documentation would be one more thing any new user picking up FilePathField for the first time would have to understand and make a decision about. For those who really want relative paths, the code in the patch for RelativeFilePathField can live outside Django core and work just fine.

I can't see how this logic holds true - like others have stated, there are already a number of options for FilePathField and this is not any harder to understand than the other options, in fact, I imagine most users would be used to the behaviour of FileField, which is stored as relative.

[Alex Hayes]

For anyone who is interested, I have taken the patch above and created django-relativefilepathfield.

Project is on bitbucket.org: ​https://bitbucket.org/alexhayes/django-relativefilepathfield

[Bernd Wechner]

I'll just and a voice of thanks to Alex Hayes for making a package available and one in critque of the justification I read from Carl Meyer which I also find does not hold water on jot. Django is littered with configurable options and RelativeFile paths are not useful in 'some' circumstances, but likely IMHO a lot, relative in particular to the BASE_DIR of the website (for files stored there, and databases that want to remain portable between different BASE_DIRs and not have file paths in these fields become erroneous.