Create Search Service

[aslakknutsen]

Related to #330

GET /api/search?q=X

200 OK
Content-Type: X

X = 'paginated search result' with opening for any 'type' (workitem, user, woritemtype, code, etc etc etc)

(only workitem relevant to this story)

[sbose78]

@pranavgore09 @baijum : Could you please review the following design ?

In search/search.go :

Let's implement the following:

• parse(..) : This should return a data structure ( define how the datastructure looks like ? ) which would have the information about what to search and on which fields.
• generate(..) : This should generate the search query which would be executed as a raw sql inside search_respository.go

The above could be part of an interface compliance. Name the interface something like Searcher and then program to the interface.

Inside search/search.go,
have a exported method called Search( searchString string ) which does the needful to
parse,generate,call DAO methods and returns a *app.Workitem[]

All the DAO methods ,ie, repository could be added inside search/search_respository.go

[baijum]

@sbose78 This looks good to me.

BTW, the return value is like this: []*app.Workitem

[pranavgore09]

@sbose78 : Yeah, looks fine as of now about methods. I am trying to do Search(r io.Reader) instead of Search(searchString string) as mentioned 2nd mistake in here.

And, It will be great to have clean search branch in the master 😃 before actually kicking off the work.

[sbose78]

Thanks @baijum and @pranavgore09 ,

Let's split this task into at least 3 PRs to master :

1. WIP: Registering the empty Search service #384 To get the empty search service.
2. @pranavgore09 : search/search.go and tests as discussed above. Search( r io.Reader) can evolve gradually because we might need to consider returning workitems+users(empty for now) etc.
3. @baijum + I : could start off with the search/search_repository.go and tests. As part of this we will read up on how to run searches using the full text capabilities of PostgreSql. We should add a lot of different kinds of tests to demonstrate that.

From a dependency perspective,
2 imports 3 .
1 imports 2 .

[pranavgore09]

@sbose78 : little confused, I am working on GenerateQueryString and TokenizeQueryString related functions. And I believe it will be in search_repo and will be consumed by point 3 above. correct ?

Rest looks fine. !

[sbose78]

Hi @pranavgore09 ,

search/search.go should house the following:

• the interface Searcher .
• the implementation of Searcher method parse : which includes all stuff to tokenize and returns a data-structure which has the information about what is to searched.
• the implementation of Searcher method generate : which generates the SQL Query.
• the exported method Search(..) : uses the above implementation to parse search string, generate SQL query and then consumes database related stuff done in search/search_repository.go to run the raw sql. The main motive is to make search.Search(..) behave like a clean API which hides all the complexity of parse,generate, db access, etc.

I've given slightly more structure to what you were already doing as part of GenerateQueryString and TokenizeQueryString.

Does this sound fine?

[pranavgore09]

Okay, so controller method Search will consume parse and generate and then pass it to repository methods. I was under impression that Search controller will not do any of such tasks. But now I am good with the structure. If we need to make controller method more abstract, we can always re-factor later.
yes, sounds good ! (thumbsup)