Bram: Andrzej Bailecki and I worked on something similar, it might be good to compare notes. I gave a talk last Activate that might be useful for you to look at for ideas.
Basically there are several issues we worked out: 1> how to insure that all segments were rewritten 2> If the schema is changing, how to update the collections one at a time even with shared configsets 3> the nuts-and-bolts of the rewriting. https://www.youtube.com/watch?v=eaQBH_H3d3g Best, Erick > On Nov 15, 2019, at 2:15 PM, Bram Van Dam <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
