Yes, absolutely to what Eric said. We goofed on news / release highlights on how to communicate what's happening in Solr. From a Solr insider point of view, we are "deprecating" because strictly speaking, the code isn't in our codebase any longer. From a user point of view (the audience of news / release notes), the functionality has *moved*.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Nov 30, 2020 at 8:04 AM Eric Pugh <ep...@opensourceconnections.com> wrote: > You don’t need to abandon DIH right now…. You can just use the Github > hosted version…. The more people who use it, the better a community it > will form around it! It’s a bit chicken and egg, since no one is > actively discussing it, submitting PR’s etc, it may languish. If you use > it, and test it, and support other community folks using it, then it will > continue on! > > > > > On Nov 29, 2020, at 12:12 PM, Dmitri Maziuk <dmitri.maz...@gmail.com> > wrote: > > > > On 11/29/2020 10:32 AM, Erick Erickson wrote: > > > >> And I absolutely agree with Walter that the DB is often where > >> the bottleneck lies. You might be able to > >> use multiple threads and/or processes to query the > >> DB if that’s the case and you can find some kind of partition > >> key. > > > > IME the difficult part has always been dealing with incremental updates, > if we were to roll our own, my vote would be for a database trigger that > does a POST in whichever language the DBMS likes. > > > > But this has not been a part of our "solr 6.5 update" project until now. > > > > Thanks everyone, > > Dima > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com < > http://www.opensourceconnections.com/> | My Free/Busy < > http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < > https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > >
