[almighty] Worried about search architecture

[Thomas Mäder]

Hi folks,

as we move to offer more search functionality in our API, I am becoming 
a bit worried about our architecture in that respect. If I look at the 
search service we have written for the "link typeahead" feature, we see 
code that parses a query string in a format that is special to this 
exact API call, and converts it directly into a query on the postgres db.

If we look at what the code does, it could be expressed like this:

|searchTerms:= parseSpecialSyntax(queryString)|

|return select * from work_items i where i.id matches(searchTearms) or 
i.title matches(searchTerms) or i.Description matches(searchTerms)|

While the first line is specific to this particular API call, the second 
part can be reused in other queries. I have tried to express this 
separation in the WorkItemRepository.List() method by passing in a tree 
of operators that describes the query instead of a query string.

I am quite open to discuss how we want to offer a search API on our 
object model to the request handlers, but I think that we need an 
internal search API layer that offers what we can search for in a 
structure way. Query parsing for special case queries (for example, 
parsing well known URLs) should not be part of this API, but done in a 
layer above. This way we can reuse a lot of checks (for example for sql 
injection) and the translation to the sql layer. I believe that we will 
write a bunch of special case queries that we will be able to map to a 
relatively simple set internal search API calls.

/Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161110/df8ea2c3/attachment.htm>