> * 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'
AFAICT, most of them can be achieved through bash/curl with one liners. Bash is supported on Windows, Mac OS and GNU/Linux. Am I missing something? On Tue, 23 May 2023 at 11:34, 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. >> > > > >> > > > >> > > >> > >> >
