We have places where there are curl/solrj alternatives in the examples. Maybe a similar widget could be used for V1/V2 examples? or even better v1/v2/solrj examples for collections api :)
On Mon, Jul 8, 2019 at 2:02 PM Gus Heck <[email protected]> wrote: > Also the Collections API docs are almost devoid of v2 examples. Just > fixing this would provide a really good reminder to those implementing > features to check that it works in v2. (unless they add features without > documenting them... which usually doesn't happen) > > On Sun, Jul 7, 2019 at 9:51 PM Noble Paul <[email protected]> wrote: > >> 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 >>> >> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
