nod I’ve gotten people fighting hard on both sides of this.
Cool, let me be the first to fight hard for configurability, then.
How about a config value for maximum size? Set it to 0 and attachments
are never stored in the database, set it to something small if your
database has trouble with large attachments, set it to something big if
your database can swallow them with no trouble.
If we put in filesystem-storage as an option it will work like this…along
with the rejection functionality i described earlier…
(it does make it a bit more trouble for the API that deals with
attachments to transparantly fetch them from the filesystem vs
database as necessary, but seems worthwhile)
nod It’s gotta be transparent to interface code. no question about that.
want to store things on disk. it gets very very icky. But someone or
other had convinced me that it was “better” to do that, than to drop
those 1/2 gig attachments into a database that could choke. The right
thing to do is probably to figure out some nice db-neutral way to chunk
things and have per-db cutoffs.
Chunking seems like the wrong solution; either the database handles large
attachments correctly or it doesn’t. If it doesn’t, why waste time with
it? Drop them in the filesystem. Especially since (as per below),
they’re fixed in the next version.
FWIW, we’ve had no end to problems with dropping attachements in the
filesystem rather than the DB in 1.0.x. For sites where I have an RT instance,
I would personally rahter have chunked content in the database than in
the filesystem. One of the things that we lose when storing in the filessytem
is the free searching that the database gets us.
jesse reed vincent — email@example.com — firstname.lastname@example.org
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
…realized that the entire structure of the net could be changed to be made
more efficient, elegant, and spontaneously make more money for everyone
involved. It’s a marvelously simple diagram, but this form doesn’t have a way
for me to draw it. It’ll wait. -Adam Hirsch