Search with mongo-like selectors

[mstn]

Apparently search is only possible with a single textual keyword. I wonder if I am right and if there is any reason for this design choice. Do you think a generic search using a kind of Mongodb query selector would make sense?

Thanks

[krishnaff]

+1 Anyone able to confirm this please? Are we locked to only one text keyword? Is there a workaround for searching with multiple keywords across multiple fields within a collection?

[steinitz-zz]

I'm also looking into this.

@mstn I hadn't thought of using mongo-like selectors, but I like the idea. My idea was to pass an object of search criteria and initialize the SearchSource object with a function to create the local-search mongo selector - similar to the current architecture when it fetches from the server.

My use case is to search using a text field and a date range. I looked closely at the search-source code and concluded that a single, text search field is in Search-Source's DNA.

Currently, I have a modified version which accepts an object for what search-source encouragingly calls the 'query', instead of only accepting a string. I've added type checks so that a simple string still works. And my modified getData now accepts a 'highlightingSearchKey' option which it uses to identify the text search string for highlighting the results - a nice, existing feature. Note that such highlighting doesn't make sense for the date range criteria.

Some smart people wrote sophisticated code which sometimes queries the server and sometimes searches its cache on the client side. I'll need to get my head around that to successfully go further with my enhancement to include the date range. My biggest challenge will likely be to replace the local search code which builds an $or query with a call to user code which builds a custom query from the passed in 'query' object key values. @mstn I'll be thinking of your idea to support mongo-like selectors while I work on that.

Onward.