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. > > > > > > > > >
