[rt-users] Option to store attachments on the filesystem
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-performance fileserver (or locally if you prefer), our database would shrink to 1.6GB. This would have numerous positive ramifications: - Database dumps/backups would finish in 1/10 the time - Database restores would finish in 1/10 the time - Planned downtimes and disaster recovery situations could be more nimbly performed (scp'ing around the db dump, restoring, etc) - Backups could be taken much more frequently - More backups could be stored - MySQL replication would be more robust with less binary data to chew on - Larger attachments could be permitted because there would be less fear of the database growing too quickly - Reduced database load querying/inserting/deleting/joining attachments I've read in previous posts to this mailing list (see below) that the arguments against this are that (1) attachments on the filesystem can't be searched and (2) the data backing the application will not be in one tidy database package but instead spread out across the db and filesystem. For our instance we don't care about #1, and for #2, while I understand the argument, I would actually argue the opposite: when attachments are on a high-performance, redundant SAN managed by a dedicated storage team that I don't have to worry about, my job administering RT just got a whole lot easier because I only have to worry about ensuring the fileserver is mounted and $AttachmentsPath (just an example config option) is properly set. I worked previously at a company that ran one of the largest instances of Bugzilla in the world and we served up 30TB of attachments over a fileserver without any problems. Can you imagine those attachments in a MySQL database? When ticket tracking syste ms are no longer small-ish, moving attachments out of the database becomes a must. I'm not asking the RT folks to switch attachment storage to the filesystem instead of the database. My wish is that RT offers its administrators the ability to choose one or the other. I know this has been a hot topic in the past, but I was hoping we could revisit the issue. Best Practical folks -- are you open to this? If so, would it help the process if I did all the work and submitted a patch? If so, should I file a bug so that we can talk about the way you would like this implemented? Given my reading of the history of this issue, I think a lot of folks would benefit from this feature. I've included previous postings about this issue below. Let me know if I can help and how I can. We would love to upstream a patch so our local instance doesn't diverge too severely from you all. Thanks for your consideration, Geoff Mayes One of the first, meaty discussions: http://www.gossamer-threads.com/lists/rt/devel/706 http://www.gossamer-threads.com/lists/rt/devel/37733 http://www.gossamer-threads.com/lists/rt/users/39507 The best discussion of the issue: http://www.gossamer-threads.com/lists/rt/users/67406 Best Practical has recently worked on this issue: http://www.gossamer-threads.com/lists/rt/users/89596 RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
Re: [rt-users] custom field autocompletion not working in IE 8?
On Wed, Dec 21, 2011 at 11:19:10AM -0500, Thomas Sibley wrote: > Hey Jim, > > On 12/20/2011 12:02 PM, jim.h.be...@frb.gov wrote: > > Slightly off topic: the custom field completion did not work at all (for > > either user) in Internet Explorer 8. Email completion works as expected. > > Can you file a bug (mail rt-b...@bestpractical.com) with some details? > Thanks! I believe this has a bugfix on 4.0-trunk and will be in the next release (it had to do with a trailing comma in the JS that made IE angry). If anyone wants to patch the fix into 4.0.4, they can do so with 91744eda7535b0489b7d302b5b6b69f5036d355c -kevin pgpHWboSM7yR2.pgp Description: PGP signature RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
Re: [rt-users] custom field autocompletion not working in IE 8?
Hey Jim, On 12/20/2011 12:02 PM, jim.h.be...@frb.gov wrote: > Slightly off topic: the custom field completion did not work at all (for > either user) in Internet Explorer 8. Email completion works as expected. Can you file a bug (mail rt-b...@bestpractical.com) with some details? Thanks! Thomas RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
Re: [rt-users] cannot get result of search Chinese character - centos 5.4
On Tue, Dec 20, 2011 at 03:53:23PM +0800, nectar wrote: > kevin, > > a. search from RT as "http://domain/Search/Simple.html?q=中文";, RT got: > Found 0 tickets > b. search database using SQL as "SELECT * FROM `rt4`.`Tickets` WHERE > ( `Subject` LIKE '%中文%' )", database got: Showing rows 0 - 0 (1 > total, Query took 0.0003 sec) > > Does it mean that we can search Chinese character from sql query, but > can not from RT web page? Please turn on $StatementLog in your config and capture the actual query that RT runs. We'd also need to see the actual Subject line stored in the Tickets table. -kevin pgpDXzJf5PXVQ.pgp Description: PGP signature RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
Re: [rt-users] Cosmetic Bug in RT 4.0.4: "Date and Time" partially visible
Dear Kevin, thanks for the quick answer - solving this particular bug is far from "mission critical" for us, so there is no hurry from our point of view. Warm regards, Stefan On 19.12.2011, at 19:00, Kevin Falcone wrote: > On Fri, Dec 16, 2011 at 08:24:17AM -0800, 20/20 Lab wrote: >> I was also able to reproduce this in Firefox 8, on an XP machine, running >> 4.0.3. Tho I cant >> say I've ever noticed it before. >> >> On 12/16/2011 12:01 AM, Stefan Vollmar wrote: >> >> Hi, >> >> we have found a bug in RT (4.0.4) related to the "Date and Time"-picker >> used to create reminders. To reproduce this bug, select a ticket and >> then click into the "Due" text box in the "Reminders" widget of the >> ticket overview. Next, select a date. If your browser window is not wide >> enough, the time selection ui will be cut off at the windows edge. We >> found this behavior using both Chromium and Firefox on Linux (see >> screenshots). It is probably present in other browsers as well. > > I believe there are two branches open about this, neither of which is > a great fix which is why we haven't merged anything down yet. > > $ git br -a | grep 4.0 | grep time > remotes/origin/4.0/datetimepicker-ui > remotes/origin/4.0/time-picker-overflow-fix > > -kevin > > > RT Training Sessions (http://bestpractical.com/services/training.html) > * Boston ˜ March 5 & 6, 2012 -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleuelerstr. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 Email: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
