I poked around it, and honestly, some of the more obscure features are kind of cool…. I can *maybe* see how they could be very useful if they weren’t so hard to find….
It may also be that since I’ve crawled through SimplePostTool and done some minor cleanups and written tests for the functionality (finding some bugs) that maybe I’m more bought in…. I think for me, the value of some of this may really come in focus once we get full on security onto Solr (for those who want it!), and that interacting with Solr via straight up curl becomes a bit more difficult, and if that becomes easier with the tools, then maybe more usage??/ I tried “brew install Solr-cli”, too bad that didn’t work, but that’s for another JIRA ;-). > On May 24, 2023, at 12:35 AM, Marcus Eagan <marcusea...@gmail.com> wrote: > > +1 on deprecating bin/post. I haven't used it in many years either. > > On Tue, May 23, 2023 at 7:30 PM Joel Bernstein <joels...@gmail.com> wrote: > >> I have mixed feelings about this because I love command line tools. But I >> haven't actually used the bin/post tool in years. >> >> >> >> On Tue, May 23, 2023 at 10:13 AM David Smiley <dsmi...@apache.org> wrote: >> >>> +1 to deprecate bin/post. >>> >>> Eric, RE the issue title... it's better. Still, if I were advocating for >>> the work (and I'm definitely not), I'd have a dedicated issue >> nonetheless, >>> may or may not even have a separate Windows issue if it gets fixed by >> side >>> effect of moving the functionality. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Tue, May 23, 2023 at 6:05 AM Eric Pugh < >> ep...@opensourceconnections.com >>>> >>> wrote: >>> >>>> Lots of feedback! >>>> >>>> So, would renaming SOLR-6994 from "Implement Windows version of >> bin/post" >>>> to “Implement Windows version of bin/post via implementing bin/solr >> post” >>>> address your concern David? >>>> >>>> It’s both for Solr technical simplicity, but also to let Window’s users >>>> actually have better support. In the not too distant future I want >> to >>>> get BASIC and JWT auth across all our CLI tools and not having this one >>>> orphaned “bin/post” and random checked in “post.jar” hanging out would >>> help >>>> that. >>>> >>>> I don’t think we can remove the capability to post documents >> completely, >>>> that it has to be deprecated. And honestly, if the darn thing worked >> a >>>> bit better (like in the aforementioned more secure scenarios) then it >>> would >>>> provide plenty of value. >>>> >>>> >>>> >>>> >>>>> On May 23, 2023, at 2:16 AM, Marcus Eagan <marcusea...@gmail.com> >>> wrote: >>>>> >>>>> Smiley, that's actually a pretty good use case. >>>>> >>>>> On Tue, May 23, 2023 at 2:15 AM David Smiley <dsmi...@apache.org> >>> wrote: >>>>> >>>>>> Glad to see we can limit this discussion to "bin/post" and not >>>>>> other non-prod/maybe-prod things listed. >>>>>> >>>>>> I think bin/post should either exist where it is or not exist; >> moving >>>> it to >>>>>> the sandbox misses the point. >>>>>> "curl" may very well be plenty adequate. FWIW your arguments work >> for >>>> me >>>>>> to ditch bin/post, but it could be useful to hear from >>>> educators/trainers >>>>>> as well. It's been a while since I could count myself as such. >>>>>> >>>>>> BTW I know of at least one advantage over curl. I was once posting >>>> massive >>>>>> many-gigabyte files to Solr in CSV (for a POC scenario). Curl >> wanted >>> to >>>>>> memory-map the whole thing and failed to get the RAM to do it. >>>> "bin/post" >>>>>> streamed the whole thing quite fast. I know I made improvements to >>>> help it >>>>>> in this specific regard. That said, if bin/post is mostly >> redundant, >>> I >>>>>> wouldn't want us to maintain bin/post forever *just* because of >> this. >>>>>> >>>>>> ~ David Smiley >>>>>> Apache Lucene/Solr Search Developer >>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>> >>>>>> >>>>>> On Tue, May 23, 2023 at 2:05 AM Ishan Chattopadhyaya < >>>>>> ichattopadhy...@gmail.com> wrote: >>>>>> >>>>>>> We have advertised the post tool in the past in our >>> examples/tutorials. >>>>>>> Difficult to erase all traces of it from the web. >>>>>>> It is better to remove the tool from the Solr distro, and, maybe, >>>>>> relocate >>>>>>> it to the sandbox/extras repo, from where a user can consciously >>> choose >>>>>> to >>>>>>> download and use it if needed. >>>>>>> >>>>>>> If we have proper documentation, I don't see how anyone building >> POCs >>>>>> will >>>>>>> miss out on the post tool. Is there a use case that users can't >>> achieve >>>>>>> easily through a documented method that the post tool caters to? >>>>>>> >>>>>>> On Tue, 23 May 2023 at 11:25, David Smiley <dsmi...@apache.org> >>> wrote: >>>>>>> >>>>>>>> Ishan, your beliefs surprise me. Maybe I'm misunderstanding your >>>> point >>>>>>> of >>>>>>>> view... is the key word of your response "advertise" and we can >> then >>>>>>> debate >>>>>>>> what that means? In other words, are you saying bin/post (and >> other >>>>>>> things >>>>>>>> you don't think should be used in production) should not exist at >>> all >>>>>> or >>>>>>> we >>>>>>>> should be very careful about how we "advertise" its existence? I >>>> think >>>>>>>> features that help people build POCs / explore / learn are good >>>> things, >>>>>>>> even if not used typically in production. At times we >>> over-advertised >>>>>>>> features without enough disclaimers on the suitability of the >>> feature >>>>>> in >>>>>>>> question. >>>>>>>> >>>>>>>> ~ David Smiley >>>>>>>> Apache Lucene/Solr Search Developer >>>>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>>>> >>>>>>>> >>>>>>>> On Mon, May 22, 2023 at 10:09 PM Ishan Chattopadhyaya < >>>>>>>> ichattopadhy...@gmail.com> wrote: >>>>>>>> >>>>>>>>>> Ishan, you did not give an argument for why you believe bin/post >>>>>>> should >>>>>>>>> go away. Do you feel it is better to document all the cURL >> commands >>>>>> to >>>>>>> be >>>>>>>>> more "standard"? >>>>>>>>> >>>>>>>>> Precisely! We should never advertise anything that shouldn't be >>> used >>>>>> at >>>>>>>>> scale or in production. That includes the post tool, example >> modes >>> of >>>>>>>>> startup, schemaless/data-driven etc. >>>>>>>>> >>>>>>>>> Curl is popular enough on Windows as well, through ports or WSL. >>>>>> There >>>>>>>> are >>>>>>>>> tools like Insomnia or Postman too. We should encourage their >> use, >>>>>>> rather >>>>>>>>> than promote our home grown tool by shipping oob and/or referring >>> to >>>>>> it >>>>>>>> in >>>>>>>>> tutorials. >>>>>>>>> >>>>>>>>> On Tue, 23 May, 2023, 3:26 am David Smiley, <dsmi...@apache.org> >>>>>>> wrote: >>>>>>>>> >>>>>>>>>> *If* bin/solr is to subsume bin/post, I think it deserves its >> own >>>>>>>> issue; >>>>>>>>>> should not be a detail of SOLR-6994 -- "Implement Windows >> version >>>>>> of >>>>>>>>>> bin/post". Really; wow that'd be sneaky to do something so >>> visible >>>>>>> to >>>>>>>>>> users / documentation under a OS/platform compatibility oriented >>>>>>> title. >>>>>>>>>> >>>>>>>>>> I am strongly not a fan of having bin/solr subsume bin/post. >>>>>>> bin/post >>>>>>>> is >>>>>>>>>> very distinct enough in purpose to remain separate. The stated >>>>>>>>> motivation >>>>>>>>>> seems out of convenience to Solr internal workings, which >> doesn't >>>>>>> serve >>>>>>>>> the >>>>>>>>>> user's best interests IMO. >>>>>>>>>> >>>>>>>>>> ~ David Smiley >>>>>>>>>> Apache Lucene/Solr Search Developer >>>>>>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 17, 2023 at 7:33 AM Eric Pugh < >>>>>>>>> ep...@opensourceconnections.com >>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> As part of SOLR-6994 I’m migrating the SimplePostTool to be >> part >>>>>> of >>>>>>>>>>> bin/solr commands. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We document a number of example use cases: >>>>>>>>>>> >>>>>>>>>>> * JSON file: bin/solr post -url >>>>>>> http://localhost:8983/wizbang/update >>>>>>>>>>> events.json >>>>>>>>>>> * XML files: bin/solr post -url >>>>>>> http://localhost:8983/records/update >>>>>>>>>>> article*.xml >>>>>>>>>>> * CSV file: bin/solr post -url >>>>>>> http://localhost:8983/signals/update >>>>>>>>>>> LATEST-signals.csv >>>>>>>>>>> * Directory of files: bin/solr post -url >>>>>>>>>>> http://localhost:8983/myfiles/update ~/Documents >>>>>>>>>>> * Web crawl: bin/solr post -url >>>>>>>>>>> http://localhost:8983/gettingstarted/update >>>>>>> https://solr.apache.org/ >>>>>>>>>>> -recursive 1 -delay 1 >>>>>>>>>>> * Standard input (stdin): echo '{commit: {}}' | bin/solr post >>>>>> -url >>>>>>>>>>> http://localhost:8983/my_collection/update -type >>>>>> application/json >>>>>>>> -out >>>>>>>>>>> yes -d >>>>>>>>>>> * Data as string: bin/solr post -url >>>>>>>>>> http://localhost:8983/signals/update >>>>>>>>>>> -type text/csv -out yes -d $'id,value\n1,0.47' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The last two, stdin and data as a string, feel rather obscure >> to >>>>>>> me, >>>>>>>>> and >>>>>>>>>>> I’d like to not port them over to being supported by the >> bin/solr >>>>>>>> post >>>>>>>>>> tool >>>>>>>>>>> equivalent. Thoughts? >>>>>>>>>>> >>>>>>>>>>> Eric >>>>>>>>>>> _______________________ >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Marcus Eagan >>>> >>>> _______________________ >>>> 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. >>>> >>>> >>> >> > > > -- > Marcus Eagan _______________________ 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.
