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
Remove custom posting formats #8746
Comments
+1 to remove them completely. Given that they are not backward compatible anyway, even if we kept it there would be a high chance that loading the index would fail. |
just to clarify, we do plan to keep the ability to inject custom written codes/posting formats from plugins, right? |
I don't think we should. We had to work hard in order to make storage more resilient to corruptions, we should not let users add more uncertainty to the system. |
+1 Adrien. I also don't think the default codec of lucene needs to support such extensibility. |
+1 lets get rid of all this. @jpountz can you take this issue? |
We discussed it and it was my understanding that due to dangerous nature of replacing codecs, we are going to remove the ability to add custom one through the settings and plugins. It will still be possible to use lucene's SPI to add codecs on the lucene level, in which case one can use them via the index.code settings. I'm +1 on that. To be clear, what I care about is removing all options to specific custom postings lists. I would be OK with not allowing to replace codecs but rather have other methods to add custom java level posting lists. |
@s1monw I'll take care of it. |
…values formats. This commit makes the `postings_format` and `doc_values_format` options of mappings illegal on 2.0 and ignored on 1.x (meaning that the default postings and doc values formats from the codec will be used in such a case). This removes a fair amount of code. Close elastic#8746 elastic#9741
Custom posting formats (eg pulsing, direct, etc) are not supported by Lucene - they provide no bwc promise. We removed the documentation before 1.4.0.Beta1, and we should prevent users from using these codecs going forward.
At the very least, we should deprecate custom codecs and refuse to create new indices that use them. I don't know how widely used these are (I'd imagine not very widely at all), but I'd be tempted to remove them completely in 2.0.
The text was updated successfully, but these errors were encountered: