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

[Amos Benari]

----- Original Message -----
> From: "Bryan Kearney" <bkearney at redhat.com>
> To: jesusr at redhat.com
> Cc: katello-devel at redhat.com
> Sent: Wednesday, June 29, 2011 11:05:46 PM
> Subject: Re: [katello-devel] initial stories for non-AR-search
> On 06/29/2011 12:22 PM, jesus m. rodriguez wrote:
> > 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.
> 
> If we can control what is searched on.. I kinda like this. It defines
> a
> REST search api.
> 
> Or.. you could define a POST with the body being search JSON. THis is
> a
> bit messier.
> 
> 
> >
> >>
> >> 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.
> 
> 
> I would be curious about a quick SWAG. This starts to sound like DSL
> generation.

The AR-search is a DSL, with auto completer.
It includes brackets, negation, logical operators, match and partial match operators etc.
It is aware of the relation between the entities, it is aware of properties type and it defines aliases to entities and properties.

On option (3) we skip the relations awareness, brackets, negation and logical 'or'. We keep logical 'and'.
We keep the matchers, partial matchers, properties type awareness and the ability to alias entities and properties.

I'll start a POC of (3) as it seems like the only option that can get us to a working solution in time, and the tasks on Pulp and Candlepin
side seems simple. I'll write down a more detailed interface for (3) and send it to the list. 
Thanks,
  Amos.

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