Allow conversation-independent search (#62) #98
Conversation
ghost
assigned 
| */ | ||
| @ApiOperation(value = "search for a conversation", response = SearchResult.class, | ||
| notes = "besides simple text-queries, you can pass in arbitrary solr query parameter.") | ||
| @RequestMapping(value = "{clientId}/search", method = RequestMethod.GET) |
There was a problem hiding this comment.
As far as I understand: You're extending the rocket-chat service endpoint for a {clientId}/search function/call. So it is ensured that I will only get results from that {clientId}? Is that right?
|
|
||
| @Service | ||
| public class ConversationSearchService { | ||
|
|
There was a problem hiding this comment.
TOP! Having a conversation search service makes absolutely sense to me, since searching conversations within the knowledge base is a core feature of Smarti itself, so this should be part of the API.
| public ResponseEntity<?> search( | ||
| @PathVariable(value = "clientId") String clientName, | ||
| @ApiParam("fulltext search") @RequestParam(value = "text", required = false) String text, | ||
| @ApiParam(hidden = true) @RequestParam MultiValueMap<String, String> queryParams) { |
There was a problem hiding this comment.
so I can use any of the supported search query parameters of Solr by simply appending these to the HTTP query string?
There was a problem hiding this comment.
Yes, but:
- the required filters for access-controll (
fq=owner:<clientId>) and type (fq=type:conversation) are always appended. - if a
text-parameter is provided, anyq-parameter passed in is replaced byq={!parent which="type:conversation"}text:<text>
|
|
||
| public SearchResult<Conversation> search(Client client, MultiValueMap<String, String> queryParams) throws IOException { | ||
|
|
||
| final ModifiableSolrParams solrParams = new ModifiableSolrParams(toListOfStringArrays(queryParams, "text")); |
There was a problem hiding this comment.
There is not much semantic within the queryParams. I could imagine that at this point it would be great to have some more meaningful "ConversationQuery" object. Or in other words: If I should make a suggestion at wich point of code I would expect most changes in future, than I would point on this part, where the Solr query is being constructed.
My question: Should we spend some efforts on how to create the query? Or should we create an improvement issue for this? Or do you think, that just using HTTP query Strings and ModifiableSolrParams is sufficient?
There was a problem hiding this comment.
I think we currently have good trade-off between simplicity and flexibility:
- the
textparameter allows simple full-text search on conversations - advanced queries can be executed by using the Solr-parameters.
If you identify additional features that should be exposed through explicit parameters (e.g. date-filters, participants, etc - just guessing) on the web-service level we can add those.
On the service level, I'd stay with the current api for now - we can add a method accepting a ConvesationSearchQuery (and a matching ConversationSearchQueryBuilder) when we need it.
|
When setting the rows parameter, the numFounds behave cumbersome. Actually the numFounds is always lower than or equals the row parameter. It seems like this is not the num founds but the cardinality of documents returned. @ja-fra should be an easy fix. |
|
After installing
|
|
No triggering is required for the global search to work. Please note that only completed conversations are considered in search. The |
Conversation-independent search is available under
${base.url}/rocket/${client.name}/searchIt accepts a
textquery parameter for full-text search, but also allows passing in arbitrary SolrRequestParams.connected to #62