ultrasphinx updates

January 12, 2008 By in Uncategorized 6 Comments

You’re already using Sphinx, right? Of course. It’s not like it’s only the fastest, most stable Rails search solution there is. At least, based on rigorous anecdotal evidence.

better docs

Lots of updates, especially Ultrasphinx deployment docs. To help the fine conductors of EngineYard.

postgres

Postgres support is now considered mature. You need at least version 8.2. Personally I found Postgres totally annoying:

Lines of stored procedures needed:

MySQL: 0

Postgres: 73

sphinx r985

With Pat Allan’s excellent Riddle, good things coming: multivalues, float faceting, geocoding.

Soon, we will get a smoother is_indexed API. I’m taking suggestions. And some time after that…delta updates. A patch would really speed that along.

The most credit goes to the Russians. I’m just connecting pipes. Got plans to explain someday why exactly Sphinx is as fast as it is. Hint: it’s not the enterprise beans!!!

6 responses

  1. Quick note to let you know you may want to update Ultrasphinx again—Riddle now supports r1065.

    I appreciate the link, too.

  3. I’m leaning towards Ultrasphinx for my new RoR project. I wonder if
    you care to read and respond to
    this post
    (in terms of Sphinx with Ultrasphinx).

    I think it will work out perfectly but you mentioned something about IDs across models/tables that I did not necessarily understand. I think you meant a unique ID across models/tables? That seems odd though.

  4. I think you’re asking if Ultrasphinx can traverse has_many associations. It can, via the :concatenate parameter in is_indexed. This uses GROUP_CONCAT to index a string from a grouping join.

    You do not have to specify any field names in the query unless you want to.

    Your example would be a lot clearer if you used the actual use case, though, and not generic identifiers.

  5. Thanks for the reply. I stumbled upon the group_concat notion late last night. Something I was not too familiar with being from the SQL Server camp and Oracle a long time ago (although I cannot recall if Oracle had its own spin on that it has been so long). Nice product you have built!

  6. About the is_indexed-API: I would consider it to be more natural, to have a weight-field on the :field definition: Most of the time, the boosting should be independent of the query—maybe you could use this value as a default and overwrite the weighting, if it gets passed into the query: that would keep all relevant configurations for the model in one place.