Hi Ken; > > The content searching problem really needs to be addressed through > the use of full-text indexing. There is currently an item in the > wiki describing how to use Oracle's full-text support with RT. Here > is the URL: http://wiki.bestpractical.com/view/OracleText. I have > not seen a similar entry for MySQL or PostgreSQL, although I will > be submitting one for PostgreSQL soon. We are upgrading to RT 3.6.x > and PostgreSQL 8.3. 8.3 supports full-text indexing as a core feature. > Maybe with two examples, someone will be able to submit a MySQL version > as well. > > If you are familiar with the full-text index support for your backend > database, you should be able to make these changes yourself. This would > provide much better performance. I think that this solution will scale > much better than just making incremental DB layout improvements. > >
Totally agree with you, and the hack I have in place is to use myisam version of the rt database (I use mysql and rt likes innodb which does not support full-text indexing), So what happens here is content searches are intercepted , the content string is queried on the myisam with full-text indexing), joins attachments and transaction table and returns a list of ObjectIds (where ObjectType = 'RT::Ticket'), the returned list of Ids are then put back into the rest to the search string as "Ticket.Id = bla or Ticket.Id = bla2 etc" .. not ideal but it actually works --most of the time -- As I said in my original mail , I would have preferred if this is addressed in the core rt development cause I am sure I am not the only one with this issue , and this kind of customisation drift from the core quite a bit Thanks; Roy _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
