Re: [rt-users] Option to store attachments on the filesystem

2011-12-23 Thread Thomas Sibley
Please keep replies on the list. For the record, I'm not claiming that core RT shouldn't support attachments on disk in the future. I'm just trying to give you the relevant info for right now. On 12/22/2011 08:58 PM, Geoff Mayes wrote: > I searched but struck out. Could you provide some links?

Re: [rt-users] Option to store attachments on the filesystem

2011-12-23 Thread Thomas Sibley
On 12/22/2011 12:43 PM, Joe Harris wrote: > I am looking into this type of functionality as well. We were > thinking of an NSF share in a web directory to drop the attachment > with a way to drop a link within the ticket. So the attachments may > not even exist on the RT server, but there will be l

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread Thomas Sibley
Hi Geoff, There exists a Best Practical written extension for putting attachments on disk, but it is not public. (Multiple mailing list posts have mentioned it in the last year.) As Ken points out, there are non-trivial issues and maintenance associated with using a database store and a filestor

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread Geoff Mayes
> I may be mistaken, but I thought that all ticket content is currently stored > as an attachment in the DB and not just those available in the Create Ticket > or > Display Ticket screens. You're right: all uploaded attachments (images, logs, PDFs, etc) as well as all textual ticket updates (com

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread k...@rice.edu
On Thu, Dec 22, 2011 at 02:17:00PM -0700, Brent Wiese wrote: > >Totally agree with this. An option to store attachments on the filesystem, > >however, is database-agnostic, so >RT admins can select this option with > >MySQL, Oracle, Postgres, SQLite, etc. > > What if it wasn't DB agnostic? >

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread Brent Wiese
>Totally agree with this. An option to store attachments on the filesystem, >however, is database-agnostic, so >RT admins can select this option with >MySQL, Oracle, Postgres, SQLite, etc. What if it wasn't DB agnostic? Does any linux/open source DB provide a "FILESTREAM" option like MS SQL?

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread k...@rice.edu
On Thu, Dec 22, 2011 at 08:42:43PM +, Geoff Mayes wrote: > Hi Kevin and Joe, > > Joe -- that's exactly what I did at a previous company where we served 30TB > of Bugzilla attachments and it worked very well. I plan to do that with RT > too. > > Kevin -- thanks so much for your detailed res

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread Geoff Mayes
___ From: rt-users-boun...@lists.bestpractical.com [rt-users-boun...@lists.bestpractical.com] on behalf of Joe Harris [drey...@gmail.com] Sent: Thursday, December 22, 2011 9:43 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] Option to store attachments on the filesystem I am

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread Joe Harris
I am looking into this type of functionality as well. We were thinking of an NSF share in a web directory to drop the attachment with a way to drop a link within the ticket. So the attachments may not even exist on the RT server, but there will be links in the ticket to a web server that houses

Re: [rt-users] Option to store attachments on the filesystem

2011-12-22 Thread k...@rice.edu
On Wed, Dec 21, 2011 at 11:12:04PM +, Geoff Mayes wrote: > Hello RT Users and Developers, > > Our RT instance at the University of Oregon is outgrowing the standard > settings in some ways. One way is with attachments. The size of our > database is 15.3GB and 13.7GB of that comes from the

[rt-users] Option to store attachments on the filesystem

2011-12-21 Thread Geoff Mayes
Hello RT Users and Developers, Our RT instance at the University of Oregon is outgrowing the standard settings in some ways. One way is with attachments. The size of our database is 15.3GB and 13.7GB of that comes from the Attachments table. If our attachments were stored on a high-performan