This is a problem. V2 APIs need a lot more metadata and nobody is doing it.
This leads to a lot of technical debt

On Fri, May 17, 2019, 3:42 AM David Smiley <[email protected]> wrote:

> I'm concerned about Solr's V2 API and the maintenance burden of attempting
> to maintain consistency with V1.  For example upon looking through the
> release notes and seeing a new exciting REINDEXCOLLECTION command (a V1
> reference), I see no corresponding adjustments in V2 --
> lucene-solr/solr/solrj/src/resources/apispec/*   It's so easy for this to
> fall out of sync.  When working on a feature affecting admin API stuff I
> need to somehow just remember/know and then ask myself if I want to test a
> new feature with just one API or both. Ugh.  Additionally, the vast
> majority of our documentation is in V1, and our help in solr-user and
> elsewhere often uses a one-liner URL to the V1 API as well.
>
> As if Solr needed more maintenance challenges than it has already (e.g.
> tests).   :-(
>
> I mainly want to point out this problem right now to see if others also
> see the problem and if anyone else has thought about it.  While working on
> Time Routed Aliases, I saw it but didn't call it out.  I thought maybe
> somehow our implementation of the admin functionality could be done
> differently so as to nearly require a V2 adjustment, and thus we don't
> forget.  For example if the V2 API was basically primary, and if it had
> metadata that described how a virtual V1 API could work based off metadata
> in the V2 apispec there that does mapping.  In this way, everything would
> work in V2 and V1 by default, or at least the majority of the time.  V2
> requires more information than V1, so if we continue to have V1 primary
> (i.e. do nothing), V2 will always be falling behind.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Reply via email to