<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><a class="moz-txt-link-freetext" href="https://github.com/almighty/almighty-core/issues/480">https://github.com/almighty/almighty-core/issues/480</a><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 11/10/2016 11:57 PM, Aslak Knutsen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CANEurse_A9xnquctYNh4V_3=kEcSdUheccPKr+3AfxXk9LMXgQ@mail.gmail.com"
      type="cite">
      <p>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. <br>
      </p>
      <p>If we look at what the code does, it could be expressed like
        this:</p>
      <p><code>searchTerms:= parseSpecialSyntax(<wbr>queryString)</code></p>
      <p><code>return select * from work_items i where <a
            moz-do-not-send="true" href="http://i.id" target="_blank">i.id</a>
          matches(searchTearms) or i.title matches(searchTerms) or
          i.Description matches(searchTerms)</code></p>
      <p>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. <br>
      </p>
      <p>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.</p>
    </blockquote>
    <br>
  </body>
</html>