[katello-devel] Searching Candlepin - Is mini_search an acceptable solution?

[Jay Dobies]

On 08/02/2011 03:17 PM, Justin Sherrill wrote:
> On 08/02/2011 11:11 AM, Amos Benari wrote:
>> A Discussion on Candlepin search API.
>> -------------------------------------
>>
>> mini_search[1] is a tiny service that is build on top Sinatra[2] and
>> uses scoped_search[3].
>> It is designed to add search API to Candlepin.
>> It exposes a simple RESTful API:
>>
>> Search: /candlepin/pools?search="the search term"
>> Auto-completer: /candlepin/pools/auto_complete_search?search="search
>> term fragment"
>>
>> The reply is a JSON representation of the search results (in this case
>> a list of Candlepin pools),
>> similar to Candlepin API call /candlepin/pools/.
>> The service access Candlepin database directly and should implement
>> Candlepin read permission model using named scopes[4].
>>
>>
>> Pros:
>> * The same search syntax as in Katello.
>> * Simple implementation.
>>
>> Cons:
>> * Another service to install and monitor.
>> * Needs to maintain the compatibility with Candlepin DB schema.
>> * Needs to maintain Candlepin read permission model compatibility.
>>
>>
>> [1] http://github.com/abenari/mini_search
>> [2] http://www.sinatrarb.com/
>> [3]
>> http://scopedsearch.wordpress.com/2011/07/11/adding-search-to-an-activerecord-rails-model/
>>
>> [4]
>> http://scopedsearch.wordpress.com/2011/08/01/permission-model-for-the-search/
>>
>>
>> Yes, if you follow the links to my blog on scoped search it does makes
>> me happy :)
>>
>> Thanks,
>> Amos.
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-devel
>
> I don't quite see how the pros outweigh the cons here? Wouldn't it make
> more sense to talk to candlepin directly so we don't have to duplicate
> database mappings? and run another service?
>
> I feel like this is giving us almost all of the drawbacks of a search
> server like lucene without giving us any of the performance gains that
> something like it would give.
>
> Are we going to do something similar with pulp even though it uses a
> no-sql db?

+1 to Justin's comments. I don't see why we'd manage all of the details 
of an outside service (one that directly looks into other applications' 
databases, which isn't all that clean) when we could just build the 
search APIs into the products themselves.

Pulp as a product has a need for searching for other users as well, it 
feels like a waste to add in that functionality outside the product when 
it makes sense to build it in. That's the purpose of us exposing REST 
APIs, so that other apps don't need to reach into our database and deal 
with keeping up with our schema.

> -Justin
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel


-- 
Jay Dobies
RHCE# 805008743336126
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org