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

Reply via email to