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

[ivan]

On Thu, Sep 21, 2000 at 11:34:21AM -0400, Jesse wrote:
> 
> 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...

Hmm, I actually have a big list of requiments for message processing that
we're currently handling outside RT now.  I'll send current design ideas
along in a separate message. 

> > (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.

:/ I dunno, if I wanted to search message text, I wouldn't use an SQL
database.  Header fields in database fields perhaps, but for searching
message bodies I'd drop them in the filesystem and use something along the
lines of Isearch / Glimpse / ht:://Dig

...anyway, i'm sure it will be configurable either way.

-- 
meow
_ivan