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.
> Am 15.11.2019 um 18:50 schrieb Bram Van Dam <bram.van...@intix.eu>: > > On 13/11/2019 20:36, Erick Erickson wrote: >> I have zero interest in having an LTS “policy†that requires any further >> commitment of my personal time to random people who ask for it but aren’t >> willing to pay. I consider my non-paid work to Solr a _volunteer_ activity, >> not something anyone has a right to demand as “supportâ€, long-term or >> otherwise. > > I hope no one is expecting you to put in free support hours based on > some random LTS designation. And if you're ever in my neck of the woods, > I'll gladly buy you a couple of beers to thank you for the effort you do > put in. > > It *is* really annoying that there is no better upgrade path than > "reindex everything and hope for the best". Making it easier to perform > in place upgrades would probably go a long way in making users happier, > and would certainly reduce the calls for an LTS version. > > I had some time off this week and I spent it poking around at the > possibility of making index upgrades easier, but I'm afraid I didn't get > anywhere with it. Too much low level Lucene stuff is involved that I'm > not familiar with (yet). > > - Bram > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P XÙ[™K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ XÙ[™K˜\XÚK›Ü™ÃBƒB --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
