"large" attachments (was Re: [rt-devel] rt notes)

[Jesse]

On Thu, Sep 21, 2000 at 05:50:19AM -0700, ivan wrote:
> On Mon, Sep 18, 2000 at 05:38:48PM -0400, Jesse wrote:
> > 
> > *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.

> > I don't
> > _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.

        -j


-- 
jesse reed vincent --- root at eruditorum.org --- jesse at fsck.com 
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