Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Mickael
    @mickael-kerjean
    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?
    Kevin Klein
    @0x002A
    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
    Marty Schoch
    @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
    Seif Lotfy
    @seiflotfy
    @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
    Marty Schoch
    @mschoch
    @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
    melbourne2991
    @melbourne2991
    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
    @melbourne2991
    @mschoch
    Marty Schoch
    @mschoch
    @melbourne2991 'th' is correct, we use ISO-639 two-letter codes
    the package was moved out of core bleve into blevex, here
    this was done because tokenizing thai requries dictionary support which is only supported by 'icu'
    icu requires cgo, and all dependencies on cgo were moved out of the core bleve
    we should update the website/docs
    Eric Sniff
    @epsniff
    Just curious, why does bleve use 16 terms for numbers and dates fields? Ref: https://github.com/blevesearch/bleve/blob/master/document/field_numeric.go#L77 Are there any papers/blogs that explain this type of encoding?
    the idea is that it makes range searches faster, because the 16 terms have different numbers of bits shifted of
    off
    Eric Sniff
    @epsniff
    Thank you, that's prefect
    melbourne2991
    @melbourne2991
    Thanks Marty
    Greg Sebastian
    @gregseb
    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
    Marty Schoch
    @mschoch
    @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
    Greg Sebastian
    @gregseb
    Fair, thanks
    Aman Gupta
    @tmm1
    what is the status of scorch? is it being used in production?
    Matt Ingenthron
    @ingenthr
    @steveyen ? ^
    Abhinav Dangeti
    @abhinavdangeti
    Apologies its been a while since I checked in here. Yes - scorch is being used in production.
    Marty Schoch
    @mschoch
    @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
    Aman Gupta
    @tmm1
    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
    Marty Schoch
    @mschoch
    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
    Marty Schoch
    @mschoch
    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
    Aman Gupta
    @tmm1
    hmm tricky. what are they using for dependency management? most of the solutions have a way to pin to tags, no?
    Aman Gupta
    @tmm1
    ah I guess I didn't realize gomodules forces the v2 path for some reason
    Vikus
    @vikusku
    Hello. What's current status of autocomplete support in bleve?