Search related

[Adhvik]

Is bleve supports partial matching? For Eg one word "testAdhvik" is indexed. How can I get a result if I search "Adhvik". Which type of mapping I have to use and which query I have to use?

Is there an "All in one" type of function that exists for searching? where I can search for all text and DateTime fields? I saw one function named "parseQuerySyntax(query string) (rq Query, err error)" for "All in one search". But I am not able to use this function in my local code.

[Marty Schoch]

See responses inline:

On Thu, Dec 24, 2020 at 9:46 AM Adhvik <patra...@gmail.com> wrote:

Is bleve supports partial matching? For Eg one word "testAdhvik" is indexed. How can I get a result if I search "Adhvik". Which type of mapping I have to use and which query I have to use?

Bleve builds an inverted index of terms.  What this means is that every document you index is broken up into smaller pieces called terms.  And every search you run, is at the lowest level and exact lookup of which documents used certain terms.

"Partial matching" is not a precise term, and means different things to different people.  By using different text analyzers and search queries, you can provide the illusion of partial matching, even though underneath it's all a set of exact lookups.

One technique to do this is using language based stemmers.  These transform terms in the document (and search query) into simpler, more root forms of the term.  This allows matches across forms of a word that are not identical.  But, this technique would not work for your example above,

Another technique is something called n-grams.  With this technique, the index is built up of smaller partial terms, with parameters min/max.  So with min of 3 and max of 5, you'd end up indexing terms like: tes,test,testa,est,esta,estad,sta,stad,stadh,tad,tadh,tadhv,adh,adhv,adhvi,dhv,dhvi,dhvik,hvi,hvik,vik

As you can see with this technique, one term in your document resulted in indexed 21 terms.  This gets too expensive quickly, but it depends on your use case.  The good news is that it would match your query, because your search term gets converted into these terms: adh,adhv,adhvi,dhv,dhvi,dhvik,hvi,hvik,vik  Since these list of terms overlap, the document would be matched.

If you choose to use this technique, you would define a custom analyzer that includes the ngram filter.

Is there an "All in one" type of function that exists for searching? where I can search for all text and DateTime fields? I saw one function named "parseQuerySyntax(query string) (rq Query, err error)" for "All in one search". But I am not able to use this function in my local code.

There is a QueryStringQuery which is intended for an end-user that types a string into a search box.  It is capable of combining text queries with date queries if you can get the syntax right (see examples in _test files).  However, we do not recommend applications manualy build up query strings.  You should directly build queries using MatchQuery or DateRangeQuery, and combine them using Conjunction, Disjunction or Boolean queries.  This is more powerful and easier to debug.

marty

[Adhvik]

As DateRangeQuery takes input only start time and end time, so how can I use this syntax ( `field:>="2006-01-02T15:04:05Z"`) for a searching date range?

Adhvik

[Marty Schoch]

You cannot do the exact query DateRangeQuery(start, end) using the QueryStringQuery.  As I said, you can compose powerful queries with this syntax, but NOT all queries.  The syntax is designed to be easy enough for a human to write, and that gives up some power.

You can however approximate this using the following:

+field:>="start-date-in-correct-format" +field:<="end-date-in-correct-format"

Note the + prefix before the field name.  This means that these clauses are required, essentially performing a logical AND.  For most use cases this will match the same documents as DateRangeQuery(start, end).  However, it is not exactly the same, as the clauses are independent, if you have multiple date values indexed in that field, this leads to different results.

I should at this point mention that I tend to discourage using QueryStringQuery.  The reason is that it's great for getting started, but at some point you're going to come back and complain that it lacks some important feature you need.  And we're not going to add it.  Applications that need their own query string should build their own.  A good query string for your application is not general purpose enough to be part of the library.

marty

--
You received this message because you are subscribed to the Google Groups "bleve" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bleve+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bleve/fb6b43ec-fa72-4d83-ac6f-ff5519723558n%40googlegroups.com.