@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
Hello. What's current status of autocomplete support in bleve?
@vikusku there is no support auto complete in bleve, it would be a nice add-on, but i've become convinced it doesn't necessarily belong inside of the core bleve
the reason is that good suggestions need to pull from dataset beyond just the term dictionary
i think you could use the vellum project (also used by bleve) as the datstructure, you'd add things you want to suggest to it, and use the iterator to walk deeper into the vellum as more keystrokes come in
but, im sure there is a lot more glue work there than i imagine