Do not generate keys that are too long for LMDB #522
Conversation
Kerollmops
added
bug
Kerollmops
changed the title
There was a problem hiding this comment.
You seem to want to unwrap each key insertion in the database, there are some in typed_chunk.rs.
Is it relevant for you to unwrap them too?
|
Why weren't we able to get the error ? And why is unwraping here a reasonable fix? |
Kerollmops
force-pushed
the
fix-lmdb-long-keys
branch
from
b4df522 to
5a8263f
Compare
Kerollmops
force-pushed
the
fix-lmdb-long-keys
branch
from
5a8263f to
211c876
Compare
|
Thank you both for your reviews, The unwraps were a mistake, sorry, I didn't take the time to review before sending the PR. It will not happen again! |
|
Build succeeded: |
|
I think I read somewhere that the maximum key size can be configured at compile time for LMDB. Is this a route worthwhile investigating? I guess there is probably some performance impact. |
|
Hey @dvic, I read that too but it, indeed, impacts the performances and I prefer that we keep most of the settings by default, it is easier to debug and the default maximum key size is already set to a big enough value (512bytes), which mean a pair of words of length ~210 bytes can fit. Thank you very much for your interest in the project! |
519: Release v0.26.4: returns facets even when there is no value associated to it + bug fix during indexation r=curquiza a=curquiza I cherry-picked the commits from these PRs - #518 - #522 `release-v0.26.4` has been started from the tag `v0.26.3` and not from main The release tag `v0.26.4` will be done on the branch `release-v0.26.4` once this PR is merge Co-authored-by: Kerollmops <clement@meilisearch.com> Co-authored-by: Clémentine Urquizar <clementine@meilisearch.com>
519: Release v0.26.4: returns facets even when there is no value associated to it + bug fix during indexation + bug fix on typo-tolerance r=Kerollmops a=curquiza I cherry-picked the commits from these PRs - #518 - #522 - #520 `release-v0.26.4` has been started from the tag `v0.26.3` and not from main The release tag `v0.26.4` will be done on the branch `release-v0.26.4` once this PR is merge Co-authored-by: Kerollmops <clement@meilisearch.com> Co-authored-by: Clémentine Urquizar <clementine@meilisearch.com> Co-authored-by: ad hoc <postma.marin@protonmail.com>
This PR fixes meilisearch/meilisearch#2338 by making sure that we do not generate keys that are too long for LMDB especially when we are creating our prefix and proximity pairs keys.