And I think v1/v2 should be split into their own servlets leveraging common code by calling utilities, or composing with other objects rather than inheriting and getting in each other's way. I think v2 could change a lot so experimental seems appropriate, but unfortunately it's been released without that moniker for a long time... we may need to go v3 if we want to change things since people will understandably have written code against it.
On Tue, Oct 26, 2021 at 11:01 PM Alexandre Rafalovitch <[email protected]> wrote: > I felt that V2's lack of support for defaults was a serious architectural > issue that is hard to just close eyes on. > > Regards, > Alex > > On Tue., Oct. 26, 2021, 3:17 p.m. Eric Pugh, < > [email protected]> wrote: > >> I’d very much like to see this as well. >> >> I’ve been thinking that I would look to migrate the Solr Admin to using >> the v2 API, and I suspect it will identify any number of gaps/areas of >> improvement in the v2 API itself. >> >> >> >> >> On Oct 26, 2021, at 3:10 PM, Jason Gerlowski <[email protected]> >> wrote: >> >> Hi all, >> >> I'm starting this thread to highlight a subject that came up in the >> recent "Solr 9.0 Release Blockers" thread: our v2 API. As a TL;DR, >> should the v2 API be considered "experimental"? >> >> We haven't explicitly called the v2 API experimental up to this point, >> but I'd argue that in essence it already is. In previous releases it >> was largely undocumented, had little or no SolrJ support, missed >> parity with v1 in terms of endpoints and parameters, and wasn't >> included in test randomization. It's hard to imagine how someone >> could have been using the v2 API nontrivially in our past releases. >> >> Treating v2 as "experimental" just feels much more like calling a >> "spade" a "spade", and sends a more accurate signal to our users. It >> would also have practical benefits: experimental code is traditionally >> free from backcompat guarantees, so an "experimental" designation >> would remove a big impediment for those improving the v2 API. >> >> Knowingly setting backcompat aside is always scary, and of course, we >> don't have any means to know for sure how many users v2 has today. >> But if we judge from the few signals we do have, the number must be >> very small. e.g. The last user-list email that mentions a v2 API path >> is "Atomic update error with JSON handler" from May of 2018! >> >> Potential backcompat breaks might inconvenience that small set of >> users, but that inconvenience would be vastly outweighed by the >> benefit to all our users of getting a cleaner, more consistent API out >> sooner. >> >> Anyway, that's my pitch. Would love to hear what people think about the >> idea. >> >> Best, >> >> Jason >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <[email protected]> >> For additional commands, e-mail: [email protected] >> <[email protected]> >> >> >> _______________________ >> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | 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. >> >> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
