Hey there, I'm evaluating different full text search solution for this project. It looks like bleve compete with the fts extension of sqlite and I'm not sure how those 2 compared together. Did someone tried both approach? I'm mostly interested in making things working on devices as powerfull as a raspberry pie, indexing data from a few gigs to a few hundreds gigs without seeing RAM or response time going overboard. Is that even possible?
Hey there. We are implementing a search engine using the default analyzer for the English language. If we search for the term "house" like in "white house" we are getting no matches because "house" is getting filtered out of the search query although it is not part of the stop word list. Any ideas why? @mschoch
@titusjaka unfortunately it won't work today, as our numeric support is limited to 64bits
there is a PR which may work, but it's not an appropriate impl, so we won't be merging that as is
@Ronll only able to delete by id's today, you'd have to fall back to searching for the keys satisfying your criteria and then doing batch deletes
@0x002A no reason i can think of for house to be filtered out
can you put together a test case showing this
@mschoch is there an easy way to just convert my current implementation to "scorch", is there a value i can set or something or do i have to reimplement things
@seiflotfy API is the same, just pass scorch.Name as the index name and kvstore name to NewUsing()
you'll have to build new index, no conversion
Hi all, can anyone tell me which language initials correspond to thai? I expected it would be "th" but that doesn't seem to exist yet the docs state that there is a prebuilt analyzer for thai language?
@melbourne2991 'th' is correct, we use ISO-639 two-letter codes
the package was moved out of core bleve into blevex, here
the idea is that it makes range searches faster, because the 16 terms have different numbers of bits shifted of
Thank you, that's prefect
Is there some common reason that a sub document mapping's DefaultAnalyzer would be ignored? The main DocumentMapping has a DefaultAnalyzer of "en" and a sub DocumentMapping on it has a DefaultAnalyzer of "keyword" but it looks like the "en" analyzer is being used on fields in the sub mapping
@gregseb unfortunately mappings are the weakest part of bleve, it is very easy to make simple mistakes that break them
the best way to troubleshooot it is to create a small sample that illustrates the problem
and share it here for others to review
what is the status of scorch? is it being used in production?
@steveyen ? ^
Apologies its been a while since I checked in here. Yes - scorch is being used in production.
@tmm1 sorry i missed this earlier. yes i agree with @abhinavdangeti multiple companies are using scorch in production now, and while we had one outstanding possible corruption issue, we just closed it. (not a scorch corruption after all, see blevesearch/bleve#1145)
im planning to fix the release (or lack thereof this week), we were close but then go modules complicated things a bit
That's great news, thanks for the update.
What's the issue with go modules? I've been spending a lot of time updating projects to use modules myself
ah maybe you can help, i don't remember all the specifics (it was about a month ago when steve and i whiteboarded it)
so, our preference is to make 1.0 upsidedown
and then immediately release 2.0 which defaults to scorch
but, i think the issue is, once you have a 2.0, it would be fine if everyone used go modules
but it becomes more of a pain (forget details here) for people not using go modules
and the 2 principal companies that have sponsored development of bleve so far, neither of them are using go modules
so, we obviously want to support go modules (like it or not that is the future)
but we have to respect those who have already adopted bleve and aren't using it yet
ah i remember more details now
bleve packages have internal references to themselves, which after 2.0 would all have to change to a /v2 path
hmm tricky. what are they using for dependency management? most of the solutions have a way to pin to tags, no?
ah I guess I didn't realize gomodules forces the v2 path for some reason