"large" attachments (was Re: [rt-devel] rt notes)
ivan-rt-devel at 420.am
Thu Sep 21 08:50:19 EDT 2000
On Mon, Sep 18, 2000 at 05:38:48PM -0400, Jesse wrote:
> On Mon, Sep 18, 2000 at 05:30:47PM -0400, Alex Pilosov wrote:
> > On Mon, 18 Sep 2000, J.D. Falk wrote:
> > > > *nod* One thing I've been vaguely pondering is the idea of storing "large"
> > > > attachments on disk, rather than in the database. This isn't something Im
> > > > thrilled with, but it may be necessary to deal with many databases' broken
> > > > large-object handling.
> > I would really strongly suggest you don't do that. Better to do it right,
> > dealing with all sillinesses of databases if necessary than do it wrong
> > way.
> *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.
(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)
> 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.
> > There aren't that many of them, its just postgres being annoying but you
> > can work around using lztext or in 7.1, it's completely fixed.
> > -alex
> 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
> They'll take my private key when they pry it from my cold dead fingers!
> Rt-devel mailing list
> Rt-devel at lists.fsck.com
More information about the Rt-devel