Indexing your Models
- Basic Indexing
- Conditions and Groupings
- Sanitizing SQL
- Multiple Indices
- Processing your Index
Everything to set up the indexes for your models goes in the
define_index method, within your model. Don’t forget to place this
block below your associations and any
calls, otherwise any references to them for fields and attributes will
indexes method adds one (or many) fields, by referencing the
model’s column names. You cannot reference model methods - Sphinx
talks directly to your database, and Ruby doesn’t get loaded at this
Keep in mind that if you’re referencing a column that shares its name with a core Ruby method (such as id, name or type), then you’ll need to specify it using a symbol.
You don’t need to keep the same names as the database, though. Use the
:as option to signify an alias.
You can also flag fields as being sortable.
Use the :facet option to signify a facet.
If there are associations in your model, you can drill down through them to access other columns. Explicit aliases are required when doing this.
There may be times when a normal column value isn’t exactly what you’re after, so you can also define your indexes as raw SQL:
Again, in this situation, an explicit alias is required.
The has method adds one (or many) attributes, and just like the indexes method, it requires references to the model’s column names.
The syntax is very similar to setting up fields. You can set aliases, and drill down into associations. You don’t ever need to label an attribute as :sortable though - in Sphinx, all attributes can be used for sorting.
Also, just like fields, if you’re referring to a reserved method of Ruby (such as id, name or type), you need to use a symbol (which, when dealing with associations, is within a method call).
Conditions and Groupings
Because the index is translated to SQL, you may want to add some custom
conditions or groupings manually - and for that, you’ll want the
As previously mentioned, your index definition results in SQL from the indexes, the attributes, conditions and groupings, etc. With this in mind, it may be useful to simplify your index.
One way would be to use something like
to generate the required SQL for you. For example:
This will produce the expected
WHERE published = 1 for MySQL.
If you want more than one index defined for a given model, just insert
define_index calls - but make sure you give every index a name,
and have the same attributes defined in all indices.
Processing your Index
Once you’ve got your index set up just how you like it, you can run the rake task to get Sphinx to process the data.
As each model is processed, you will see a message much like the one below. It is just a warning, not an error. Everything will work fine.
However, if you have made structural changes to your index (which is anything except adding new data into the database tables), you’ll need to stop Sphinx, re-index, and then re-start Sphinx - which can be done through a single rake call.