[almighty] Worried about search architecture

[Thomas Mäder]

https://github.com/almighty/almighty-core/issues/480


On 11/10/2016 11:57 PM, Aslak Knutsen wrote:
>
> 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 <http://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.
>

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