Search within the whole app

[Dmytrii Nagirniak]

Hi,

I wonder if anybody has recommendations implementing application wide search (you know, the **small** box on the top right).

It should search among different kinds of modes with very little (if anything) in common.

How would you approach this?

Not sure that Thinking Sphinx, ElasticSearch etc are good fit for that.

Thanks,

Dmytrii

[Paul Annesley]

With ThinkingSphinx, you can do something like:

ThinkingSphinx.search(search_term, classes: [ SomeModel, AnotherModel ])

The return value is a mixed-type collection of model objects.

Your view could then delegate to a different partial view for each type.
I guess this (HAML) would do that automatically:
- @results.each do |result|
= render result

I had a similar requirement, but the result objects had almost-the-same interfaces, so instead of using Rails partials I wrote a MethodHuntingDelegator to provide a uniform interface across the results:
http://paul.annesley.cc/2012/01/methodhuntingdelegator/

-- Paul

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To post to this group, send email to rails-...@googlegroups.com.
> To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Chris Berkhout]

I think a search engine probably is what you're after.

Since this is just simple text search, if you're using Postgres you
could just put a text field in each record of content you want to make
it searchable on, and use Postgres' built in full text indexing.

Do you have other specific concerns?

Cheers,
Chris

[Dmytrii Nagirniak]

On 14/02/2012, at 4:44 PM, Paul Annesley wrote:

With ThinkingSphinx, you can do something like:

ThinkingSphinx.search(search_term, classes: [ SomeModel, AnotherModel ])

The return value is a mixed-type collection of model objects.

Thanks. Good to know that. Haven't used Thinking Sphinx before.

I had a similar requirement, but the result objects had almost-the-same interfaces, so instead of using Rails partials I wrote a MethodHuntingDelegator to provide a uniform interface across the results:
http://paul.annesley.cc/2012/01/methodhuntingdelegator/

I didn't know about the Delegator class in Ruby. Looks like method_missing on steroids :)

[Andrew Harvey]

We're working on something very like this at Westfield. I'm working on using field collapsing (aka. Grouping) to achieve this. That will allow us to compare apples to apples as it were, rather than having disparate result sets being merged and scored together. The trick comes when different filters are required against different objects.

Andrew

Sent on the run.

[Dmytrii Nagirniak]

On 14/02/2012, at 4:50 PM, Chris Berkhout wrote:

> Since this is just simple text search, if you're using Postgres you
> could just put a text field in each record of content you want to make
> it searchable on, and use Postgres' built in full text indexing.

Yeah, that may work too... (for better or worse will have to use PG during testing then instead of SQLite).

> Do you have other specific concerns?

Yep. The indexed data is different for each user depending on the permissions.

So the same search term will return completely different results for each user and depending on the current context (subdomain).

This I guess is the most challenging part.

[Chris Berkhout]

> Yep. The indexed data is different for each user depending on the permissions.
> So the same search term will return completely different results for each user and depending on the current context (subdomain).

Okay. I'm doing something similar at the moment with ElasticSearch
(via the Tire gem). The trick is just having the right flags in the
index and adding a filter (actually, a boolean query) based on the
user's permissions when building the query.

Exactly how you do it will depend on the details of your schema and
data. If each user's data is completely separate, another option with
ElasticSearch is to use a different index for each user.

Not sure if there are other things that specifically address this use
case. PG may allow you to do a join before applying the FTS part. PG
in testing sounds fine to me, unless you have an inflexible CI
environment to think about.

Cheers,
Chris

[Tim Uckun]

Try pg_search if you are using postgres. It seem to tick your boxes.

https://github.com/Casecommons/pg_search

[Dmytrii Nagirniak]

On 14/02/2012, at 5:59 PM, Tim Uckun wrote:

> Try pg_search if you are using postgres. It seem to tick your boxes.
>
> https://github.com/Casecommons/pg_search

It sounds like using PG FTS is the best bet in my case.

I wonder when/why one would use pg_search and texticle?

Any experience with either of those? texticle seems to be more popular and mature according to Ruby Toolbox.

[Dmytrii Nagirniak]

On 14/02/2012, at 5:30 PM, Chris Berkhout wrote:
> Okay. I'm doing something similar at the moment with ElasticSearch
> (via the Tire gem). The trick is just having the right flags in the
> index and adding a filter (actually, a boolean query) based on the
> user's permissions when building the query.
>
> Exactly how you do it will depend on the details of your schema and
> data. If each user's data is completely separate, another option with
> ElasticSearch is to use a different index for each user.

Thanks. It sounds like a reasonable approach to take.

> Not sure if there are other things that specifically address this use
> case. PG may allow you to do a join before applying the FTS part. PG
> in testing sounds fine to me, unless you have an inflexible CI
> environment to think about.

As far as I can see the PG FTS is the most pragmatic approach for now.
Will probably take that route.
Now need to skip over my reading queue with a good PG book :)

[Matthieu Stone]

Not simple, but a few other ideas..

Sunspot => http://sunspot.github.com/  - some people don't like it.. but it's worked for me.

However, lately I've been using Redis to create my own indexes - super duper fast, but you really need to think through what you are doing.

Your mileage may vary.

rgds,

- amtt.

[Dmytrii Nagirniak]

On 15/02/2012, at 4:35 PM, Matthieu Stone wrote:

Not simple, but a few other ideas..

Sunspot => http://sunspot.github.com/  - some people don't like it.. but it's worked for me.

However, lately I've been using Redis to create my own indexes - super duper fast, but you really need to think through what you are doing.

Didn't think of using Redis that way. Interesting option.

But generally whicever search engine I am going to use, I still have to either "post process" the results according to users' permissions or carefully craft the indexing so that results reflect the permissions.

The 2nd option feels more trouble than it's worth. With "Post processing" I'm afraid of the perf issues that will come out of it.

Also Redis, Solr, ElasticSearch etc is additional maintenance.

So I tend to think of PG FTS as the best fit for now.

But it was great to hear all the options here.

Thanks you all guys.

[Nicholas Faiz]

PG FTS sounds like a good bet, and you might find the performance isn't an issue.

But, depending on how you've structured permissions in your database, you could probably use solr (and most other search engines) to generate search results according to the current user's permissions, so there wouldn't be the post-processing phase.

Cheers,

Nicholas