I know of divisions of very large companies that have specifically done this, and even a product that wrote their "integrate with solr" suggesting to use post.jar and then sold to customers saying that they supported solr integration.
post.jar should die. The "stream a large file" use case should be handled, but I think the tool should be just for that and documented as only for that use case. On Tue, May 23, 2023 at 2:16 AM Marcus Eagan <marcusea...@gmail.com> wrote: > I agree with Ishan on the post tool, specifically. The problem may be that > people have built other tools and integrations around it. > > Postman has accelerated cURL's growth for another class of users. Look at > all this content about cURL and Postman if you are unfamiliar > < > https://www.google.com/search?q=curl+usage+postman&oq=curl+usage+postman&aqs=chrome..69i57j0i22i30l2j0i390i650l3.3310j0j7&sourceid=chrome&ie=UTF-8 > > > . > > > On Tue, May 23, 2023 at 2:10 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > > In fact, doing these via curl will be more instructional to a user who is > > using Solr for the first time. He/she will likely already know how curl > > works, so will not assume there's magic happening under the hood in the > > post tool. > > > > On Tue, 23 May 2023 at 11:38, Ishan Chattopadhyaya < > > ichattopadhy...@gmail.com> wrote: > > > > > > * 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. > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >> > > > > > -- > Marcus Eagan > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
