Feature #1039


Ability to store attached files in the database

Added by Carl Nygard almost 15 years ago. Updated almost 15 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Wont fix


Perhaps I don't know all the tradeoffs, but I think not storing attachments directly in the database is a mistake. Keeping attachments locally in the redmine project directory can be a gotcha for people, especially in regards to backups. Having to backup the redmine project directory in addition to the database is not obvious.

Adding the attachments to the database means one entity to backup, one entity to restore (or migrate). Also allows redmine to be proxied across machines in a cluster for load balancing without doing special filesystem sharing.

Actions #1

Updated by Rocco Stanzione almost 15 years ago

The idea of storing files in the db may have some merit, but this is clearly a design decision and not a defect.

Actions #2

Updated by Karim Trott almost 15 years ago

What about using git for storing files / documents / attachments ? Furhtermore I would like to see an extended/improved document management on redmine.

Actions #3

Updated by Jean-Philippe Lang almost 15 years ago

  • Subject changed from attached files not stored in the database to Ability to store attached files in the database
  • Category changed from Administration to Attachments
  • Priority changed from High to Normal
  • Target version deleted (0.7)

As Rocco said, it's not a defect.

Actions #4

Updated by Rocco Stanzione almost 15 years ago

This would make an excellent feature as a configurable option for the reasons Carl mentioned.

Actions #5

Updated by Paul Rivier almost 15 years ago

Storing standalone files in databases is just totally missing the point of what filesystems are made for. I admit one might like the idea of a single-point, network-enabled, access to all the data. But putting blobs in the DB is a poor design, really. Jean Philippe was right in his design.

If you want single-point access to the data, accessible through network, do not put blobs in the DB, this will not be the correct design. Better write an abstraction client/server layer, let's call this a proxy, between RedMine data access and actual data storage. You might find inspiration from the ZEO / ZODB design for Zope, although I would not recommend to mimic it entirely.

Actions #6

Updated by Thomas Meeks almost 15 years ago

I can think of a lot of good reasons to not toss files into the database:

  1. It balloons the db size, making backups take longer.
  2. It puts extra work on the db, which has plenty to do as is.
  3. It means files would have to be serialized through rails (because there is no file for the webserver to point to) -- which means that rails process will block incoming web requests while the file is being downloaded. There are ways around this, but they are really hackish, or don't lend well to simple deployments.
  4. There are a ton of database "gotchas" that ActiveRecord can't abstract away when dealing with blobs.

Plus, backing up files is exceedingly easy. Just rsync them to another box. I admit it might not be blatantly obvious that you need to do it, but I think that's a point for documentation rather than creating a ton of work with little real-world benefit.

If you need single-point access to the data over a network, just use a NFS/SMB share. It is plenty fast for attachments.

Actions #7

Updated by Carl Nygard almost 15 years ago

If it's a bad idea, then I suggest dropping the feature. If so, I'll file feature request for configurable storage location and a backup script that backs up the db, attachment files, and configuration to some specified location.

Can someone determine if the attachment files are migrated to the new redmine installation directories when upgrading between Redmine versions?

Actions #8

Updated by Jean-Philippe Lang almost 15 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

I've added a few words about this at the end of RedmineInstall guide.


Also available in: Atom PDF