Re: [rt-users] Searching Ticket Bodies
On 01/08/2013 10:11 AM, Tim Gustafson wrote: Is there any way to search the bodies of tickets, replies and comments? In the advanced search editor I don't see those columns listed in any of the search parameters. http://bestpractical.com/rt/docs/latest/RT_Config.html#FullTextSearch http://bestpractical.com/rt/docs/latest/full_text_indexing.html These are also shipped with RT itself as doc in etc/RT_Config.pm and docs/full_text_indexing.pod.
Re: [rt-users] Searching Ticket Bodies
http://bestpractical.com/rt/docs/latest/RT_Config.html#FullTextSearch http://bestpractical.com/rt/docs/latest/full_text_indexing.html These are also shipped with RT itself as doc in etc/RT_Config.pm and docs/full_text_indexing.pod. Hrmm, I remember now. That documentation states: MySQL does not support full-text indexing natively. Which is untrue. MySQL does indeed have full-text indexing, and the most recent version has full-text indexing with InnoDB tables. Is there any hope for taking advantage of the FTS built-in to MySQL? My MySQL server does a *lot* more than just RT, and re-compiling the whole thing with an add-on that gets used by exactly one database (out of, let's say, 400 databases) seems sub-optimal. -- Tim Gustafson t...@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A
Re: [rt-users] Searching Ticket Bodies
On Tue, Jan 08, 2013 at 11:08:20AM -0800, Tim Gustafson wrote: http://bestpractical.com/rt/docs/latest/RT_Config.html#FullTextSearch http://bestpractical.com/rt/docs/latest/full_text_indexing.html These are also shipped with RT itself as doc in etc/RT_Config.pm and docs/full_text_indexing.pod. Hrmm, I remember now. That documentation states: MySQL does not support full-text indexing natively. Which is untrue. MySQL does indeed have full-text indexing, and the most recent version has full-text indexing with InnoDB tables. Is there any hope for taking advantage of the FTS built-in to MySQL? My MySQL server does a *lot* more than just RT, and re-compiling the whole thing with an add-on that gets used by exactly one database (out of, let's say, 400 databases) seems sub-optimal. -- Tim Gustafson t...@soe.ucsc.edu 831-459-5354 Baskin Engineering, Room 313A Hi Tim, Per the web site www.mysql.com, the version of MySQL with native InnoDB support is not yet released. (5.6) Once it is released, it would be possible to include support for it. Until that happens, your options are to compile a new build with the needed functionality, use a different version for RT, or use a different DB entirely. PostgreSQL and Oracle both support it natively currently. Regards, Ken
Re: [rt-users] Searching Ticket Bodies
On 01/08/2013 11:08 AM, Tim Gustafson wrote: Hrmm, I remember now. That documentation states: MySQL does not support full-text indexing natively. Which is untrue. MySQL does indeed have full-text indexing, and the most recent version has full-text indexing with InnoDB tables. Is there any hope for taking advantage of the FTS built-in to MySQL? My MySQL server does a *lot* more than just RT, and re-compiling the whole thing with an add-on that gets used by exactly one database (out of, let's say, 400 databases) seems sub-optimal. As Ken noted in his reply, MySQL 5.6 with InnoDB FTS hasn't reached a non-developer release yet (what they call general availability, GA). Additionally, the initial FTS support in 5.6 doesn't look promising for a quick turnaround to get it supported in RT. Two technical hurdles: 1) There is no native support for stemming in the DB, which is quite important for content searches. This means RT would need to do its own stemming as a preprocessing step before handing the query to MySQL. Pg, Oracle, and Sphinx support this natively. 2) Only TEXT columns may be FTS indexed; on MySQL, the Attachments.Content column is currently a BLOB since it is also used to store binary data. Additionally, partial full text indexes aren't supported, so binary and textual content will have to be entirely split, not just encoded as under Pg. As an incredibly large upgrade step of some sort or another, RT is probably going to need to make schema changes to the Attachments table. This is the largest table in big installs by orders of magnitude, so executing the schema changes as correctly and efficiently as possibly is key. It will take significant engineering and testing effort. All this is to say, Don't hold your breath. :) Ken lists a number of alternatives, such as isolating a MySQL instance with Sphinx from your primary MySQL instance.
Re: [rt-users] Searching Ticket Bodies
On 01/09/2013 05:08 AM, Tim Gustafson wrote: http://bestpractical.com/rt/docs/latest/RT_Config.html#FullTextSearch http://bestpractical.com/rt/docs/latest/full_text_indexing.html These are also shipped with RT itself as doc in etc/RT_Config.pm and docs/full_text_indexing.pod. Hrmm, I remember now. That documentation states: MySQL does not support full-text indexing natively. Which is untrue. MySQL does indeed have full-text indexing, and the most recent version has full-text indexing with InnoDB tables. Is there any hope for taking advantage of the FTS built-in to MySQL? My MySQL server does a *lot* more than just RT, and re-compiling the whole thing with an add-on that gets used by exactly one database (out of, let's say, 400 databases) seems sub-optimal. MySQL = 5.1 can use sphinx as a plugin. You might be able to find a pre compiled library for your system, otherwise you can compile the plugin yourself. See :http://www.howtoforge.com/sphinx-as-mysql-storage-engine-sphinxse Cheers, Jeff.
