Searching Ticket Bodies

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.

Tim Gustafson
tjg@soe.ucsc.edu
831-459-5354
Baskin Engineering, Room 313A

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.

RT Config - RT 5.0.5 Documentation - Best Practical
Full text indexing - RT 5.0.5 Documentation - Best Practical

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
tjg@soe.ucsc.edu
831-459-5354
Baskin Engineering, Room 313A

RT Config - RT 5.0.5 Documentation - Best Practical
Full text indexing - RT 5.0.5 Documentation - Best Practical

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
tjg@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

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.” :slight_smile: Ken lists a number of
alternatives, such as isolating a MySQL instance with Sphinx from your
primary MySQL instance.

RT Config - RT 5.0.5 Documentation - Best Practical
Full text indexing - RT 5.0.5 Documentation - Best Practical

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
:Sphinx As MySQL Storage Engine (SphinxSE)

Cheers, Jeff.