[katello-devel] initial stories for non-AR-search

[jesus m. rodriguez]

On 06/29/2011 11:41 AM, Amos Benari wrote:
[snip]

>> So... what would this look like for Candlepin then? How would I show
>> systems with a fact X = Y?
>
> My line of thinking of the interface definition is like this:
>
> The search language is a "humanized language", the search plugin translate it into the relevant database SQL statement.
> If I'll define an interface-language the result will be "humanized" translated to "interface" translated to "SQL", this seems wrong to me.
> Two translations on different platforms are just doubling the pain.
>
> This leads me to two alternatives:
> 1. Send "humenized" query to the remote system
> 2. Send "SQL where clause" / "MongoDB-JSON" as an interface. To do that we need to:
>      a. Model the remote database on Katello.
>      b. Sanitize the SQL on the receiving side to prevent SQL injections.
>
> Option (1) works fine for Foreman integration because it's API already expose the relevant "humenized" search. We might need to solve an issue with the different terms used in Foreman and Katello (hostgroups in foreman are templates in Katello etc.) but this is probably not that difficult.
> Option (2) will be possible solution for Pulp search after I'll expend the search plugin to support MongoDB.
> Option (2) can be a solution for Candlepin if "SQL where clause" is OK as an API.

I don't like the idea of sending SQL, sanitized or otherwise, through
the API. To me this is a recipe for disaster.

>
> The obvious drawbacks of (2) is:
> A. It exposes the database structure to the API.
> B. non-ruby clients will have a hard time using this API.
>
> If the above solution (2) is not acceptable and we can go in one of the following alternatives:
> 3. Have a limited search capabilities embedded into the API. (I think this is more or less what Mike was referring to)
>     e.g. have an API Package.get_by_repo(repo_id, filter, order_by, skip, limit)
>     - filter is a condition over package.
>     - order_by used for sorting.
>     - skip and limit is used for paging.
>   (in REST it would look something like "/repos/repo_id/packages?filter=[name~'foo*',arch='x86_64']&order_by=['name','acs']&skip=0&limit=20")

+1 I'm ok with option 3 having a limited search capability in the API.

>
> In this solution the API will be larger, the search capability are going to be some what limited, and the search needs to be implemented in Pulp and Candlepin for each API,
> but it's simple to implement.
> On the Katello side we are left with a parser and auto-completer to implement.
>
> 4. Implement "humanized" search in Java and Python, this can be fun, if we are interested in this direction I'll need to evaluate the cost.

+2 I'd rather see this implemented as it could be of more general use in
the future.

jesus

-- 
jesus m. rodriguez          | jesusr at redhat.com
principal software engineer | irc: zeus
red hat systems management  | 919.754.4413 (w)
rhce # 805008586930012      | 919.623.0080 (c)
+---------------------------------------------+
|   "Those who cannot remember the past       |
|    are condemned to repeat it."             |
|                        -- George Santayana  |
+---------------------------------------------+