-
Notifications
You must be signed in to change notification settings - Fork 1.1k
nouveau: Upgrade to Lucene 10 #5628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
ffbe402
to
92b38b2
Compare
7b26d9f
to
769bc65
Compare
Just to be sure: without the scanner plugin, the index version is not automatically written into the design doc, right? We have a whole set of Nouveau indexes and views in a single design doc. Adding the version would trigger a rebuild of all indexes, which we want to avoid. |
Avoiding query-blocking rebuilds is the highest priority of this work, so thank you for the comment. The lucene_version field is injected on interactive edits (when you create or modify a design document). Since that edit would be a new index anyway, that it happens to be a Lucene 10 index is fine. It's one set of index builds. There might be some refinements to this before the PR is merged for the case where a design document defines multiple indexes. The absence of the lucene_version field is taken to mean the index, if it exists on the nouveau server, is for Lucene 9. The index signature includes the lucene version from 10 onward and omits it for version 9 (so that the sig remains unchanged on upgrade). |
I've pushed an update so that the lucene_version injection only occurs for new design documents, not updates to them. |
1) the Dropwizard framework (https://dropwizard.io) | ||
2) Java 11+ | ||
3) Lucene 9 | ||
2) Java 21+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense as that seems to be the lowest supported Java version for Lucene 10. But I think this will force us to move to Debian Trixie with the packaging if we go with using built-in java packages. If we switch to 3rd party ones it wouldn't matter. Swtiching to Trixie is probably the better option. Not a showstopper, of course, just leaving a note so we don't forget.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's the main upgrade pain, that Debian oldstable is too old.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's not too much to ask, please don't drop support for Debian 12. We have several customer installations where it is not possible to upgrade to Debian 13 in the near future, but we want to keep updating CouchDB. It would be no problem for us to install a 3rd-party JVM. Support for Trixie is also nice for new Systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't drop support for Debian 12. The only thing you need to do is to install a 3rd-party VM (Java 21+) on Debian 12.
-include_lib("couch/include/couch_db.hrl"). | ||
|
||
%% New index definitions get an explicit lucene version property, if missing. | ||
before_doc_update( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a neat approach.
Wonder what would happen if users would toggle the version by hand (bump it up, down, make it a non-integer) or just remove it after it was created? Would that break the index or crash anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried to consider various manual shenanigans while trying to make the Java side stick to a "the version of Lucene I am using now plus the one before" without hardcoding "10" and "9" everywhere. I will review that aspect again as I think there are gaps (e.g, I want it to be an error to set lucene_version to anything but 10
or 9
and have that handled well (i.e, no stack traces, no erlang process crashes, just an error message in the log or in the http response)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Revised commit "Allow existing legacy indexes but prevent new ones" so it only allows 9 or 10.
91eacb4
to
de25207
Compare
5a8c42d
to
cb4b90f
Compare
I gave this a try with this test script. Without adding an explicit #!/bin/bash
set -x
http -b post $DB/_nouveau_analyze analyzer=standard text=for@bar@baz
http -q delete $DB/ndb
http -q put $DB/ndb
http -q post $DB/ndb/_bulk_docs docs:='[{"_id":"1","a":"xxx"},{"_id":"2","a":"xxx"},{"_id":"3","a":"zzz"},{"_id":"4","a":"xxx"}]'
http -b put $DB/ndb/_design/nd1 nouveau:='{"idx1": {"index":"function(doc){index(\"string\",\"a\",doc.a,{\"store\":true})}"}}'
http -b post $DB/ndb/_design/nd1/_nouveau/idx1 q="a:xxx" limit:='2'
#!/bin/bash
set -x
http -b post $DB/_nouveau_analyze analyzer=standard text=for@bar@baz
http -q delete $DB/ndb
http -q put $DB/ndb
http -q post $DB/ndb/_bulk_docs docs:='[{"_id":"1","a":"xxx"},{"_id":"2","a":"xxx"},{"_id":"3","a":"zzz"},{"_id":"4","a":"xxx"}]'
# http -b put $DB/ndb/_design/nd1 nouveau:='{"idx1": {"index":"function(doc){index(\"string\",\"a\",doc.a,{\"store\":true})}"}}'
# http -b post $DB/ndb/_design/nd1/_nouveau/idx1 q="a:xxx" limit:='2'
http -b put $DB/ndb/_design/nd2 nouveau:='{"idx": {"lucene_version":9, "index":"function(doc){index(\"string\",\"a\",doc.a,{\"store\":true})}"}}'
http -b post $DB/ndb/_design/nd2/_nouveau/idx q="a:xxx" limit:='2'
|
9ad011e
to
0bb8604
Compare
Overview
Upgrades Nouveau to Lucene 10.
Existing indexes can still be queried and updated. New indexes will be built with Lucene 10 (couchdb will auto-inject the version information into the design document).
A couch_scanner plugin will build Lucene 10 versions of all current indexes (sequentially) and update the design document on successful completion, making the upgrade automatic.
TODO:
NOTES
Lucene 10 raises the JDK requirement from 11 to 21.
Testing recommendations
TBD
Related Issues or Pull Requests
N/A
Checklist
rel/overlay/etc/default.ini
src/docs
folder