Storing of attachments

This isn’t a new idea, but I’ve not seen anyone talking about it recently
on the lists, so it may be new to RT.

Some attachment types (gif,jpeg) aren’t really all that useful for search
purposes in the database. Also very large attachments tend to be painful.

What I’m looking for is a way to store these on disc outside of the
database itself.

What comes to mind is a mechanism where appropriate attachments just get
saved into a filesystem accessible to the webserver. These can then be
referenced direct from disc by ShowTransaction.

I’ve not fully thought through the pros and cons - quickly I can see:

Advantages:

  1. Database doesn’t grow as quickly.
  2. Attachments on disc can be purged more simply.

Disadvantages:

  1. Attachments aren’t (easily) searchable.

Some care needs to be taken as to how they are stored on disc, which a DB
would do for you.

Implementationwise, I can see adding various attachment ‘types’ (possibly
by introducting pseudo-mime types) for an attachment on disc, an
attachment which has been dropped/deleted. Possibly more. I can also
see allowing for attachments to be deleted via the gui. This would be
useful for the more unpleasant forms of spam which pass through our spam
filters - really don’t want that sort of thing clogging up our DB!

Has anyone looked down this sort of line of development before? And if
not, any comments before I do so myself?

Thanks.

John

What I’m looking for is a way to store these on disc outside of the
database itself.

Advantages:

  1. Database doesn’t grow as quickly.
  2. Attachments on disc can be purged more simply.

That could be taken care of with a tool

Disadvantages:

  1. Attachments aren’t (easily) searchable.
  • Backups are harder
  • Redundancy is harder
  • Every frontend RT server needs to talk to a common filesystem
  • RT needs to read and write to the filesystem

What I’m looking for is a way to store these on disc outside of the
database itself.

Advantages:

  1. Database doesn’t grow as quickly.
  2. Attachments on disc can be purged more simply.

That could be taken care of with a tool

Are we always this dismissive? :slight_smile:

Maybe, but I’d still like a stub attachment to show in the ticket.

Currently if one runs with the default settings -
$RT::TruncateLongAttachments and $RT::DropLongAttachments undefined -
large attachments get silently dropped. (setting DropLongAttachments
causes a log message, but if neither is set the code falls through and
does nothing).

I’d like at least a note in the ticket that this has happened.

Also it’s not just a case of purging attachments - some I just don’t want
to be in there in the first place - what is the merit of keeping the image
files in there? I can’t usefully search them by content.

The other large attachments we get tend to be data that is needed once by
someone. I’d like to make that available without stuffing very large
attachments into my DB. Having it on disc where it can be downloaded and
then manually removed would fit our usage pattern quite neatly.

John