Code

Opened 6 years ago

Closed 3 years ago

Last modified 2 months ago

#6896 closed New feature (wontfix)

Add ability to store only relative paths in a FilePathField

Reported by: graham.carlyle@… Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: eschler@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

6896.diff (6.6 KB) - added by seniorquico 4 years ago.
Adds a "RelativeFilePathField"

Download all attachments as: .zip

Change History (17)

comment:1 Changed 6 years ago by programmerq

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 5 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to Database layer (models, ORM)

comment:3 Changed 5 years ago by gregplaysguitar

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.

comment:4 Changed 4 years ago by deschler

  • Cc eschler@… added

Changed 4 years ago by seniorquico

Adds a "RelativeFilePathField"

comment:5 Changed 4 years ago by seniorquico

  • Patch needs improvement set

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.

comment:6 Changed 4 years ago by seniorquico

  • Has patch set

comment:7 Changed 3 years ago by gg

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

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by julien

  • Type set to New feature

comment:10 Changed 3 years ago by julien

  • Severity set to Normal

comment:11 follow-up: Changed 3 years ago by carljm

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed
  • UI/UX unset

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.

comment:12 Changed 3 years ago by 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.

comment:13 Changed 21 months ago by 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.

comment:14 Changed 17 months ago by 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....

comment:15 in reply to: ↑ 11 Changed 2 months ago by zanuxzan

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.

comment:16 Changed 2 months ago by zanuxzan

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.