On 15/11/2019 19:14, Jörn Franke wrote: > Well sometimes even reindexing might not always be avoidable when upgrading. > However, there should be a more user friendly way. Not every Solr deployment > that one might inherit has foreseen this. Eg in case Solr is used as a NoSQL > database where the application puts data in Solr, but not outside Solr for > the case of reindexing. In those case it would be useful that Solr can > (configurable) write the original SolrInputDocument somewhere and this > original document can then be user for reindexing in case of major updates.
Writing the SolrInputDocument to disk would get really expensive really quickly. When all fields are stored it's relatively easy to build a new index from an old one. But when you have a any non-stored fields, things become a bit less convenient. In some cases you can uninvert the field and recreate the content based on the terms used. Still tricky. A way to perform in-place updates in Lucene would help in this case. But that seems hard to implement, and it would only help with this particular upgrade problem. When I have more time I'll keep hacking away on an upgrade tool that works for our use-case. If it turns out to be usable for anyone else, I'll give it back to the community. Also; not sure why the MS mail servers are messing up some of my mails. Apologies. - Bram
