I say this despite the fact I know it will break some folks because anyone relying on post.jar for a non-trivial use case will either have such a horrible experience that they eventually move to elastic/opensearch or they will write their own code anyway. The harm to future users is heavier.
On Tue, May 23, 2023 at 9:58 AM Gus Heck <gus.h...@gmail.com> wrote: > 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) > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
