Documentation needs maintenance long term -- it can say things or show snippets that aren't true eventually or eventually stop working. Just keep that in mind.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Thu, Apr 29, 2021 at 4:19 PM Eric Pugh <[email protected]> wrote: > I’d be interested in picking up the baton on that idea…. I could see > adding both a curl example, but also a native Powershell example. Curl > on windows is also an alias to powershell methods, so it doesn’t quite work > always. I could imagine have three tabs to demonstrate this. > > > On Apr 29, 2021, at 3:43 AM, Jan Høydahl <[email protected]> > wrote: > > Yea, let's add some warnings and keep post tool for demo purposes. > Perhaps in the tutorial > https://solr.apache.org/guide/8_8/solr-tutorial.html we could add cURL > examples for indexing the data as well as post.jar (using tabs like we do > with v1/v2 api)? > We can also do a better job suggesting where to look for proper filesystem > / web crawlers for those who need that. > And as SimplePostTool is not either a good example of how to integrate > with Solr in Java, we could really need a Solr SDK with code examples of > integration best practices and "ready-to-use" snippets, using SolrJ. > > Jan > > 28. apr. 2021 kl. 22:45 skrev Gus Heck <[email protected]>: > > I've generally been of the impression/opinion that the Post Tool is really > just a convenience for folks testing out solr to see what it can do, and > not really meant as a production ingestion solution. > > A little while back I had a client that had a third party tool that > "integrated with solr" by invoking post.jar on documents with a script to > loop through all the files in a directory and post them (the third party > software's direct example of how to integrate, not the client's idea at > all). Needless to say this caused difficulties with the gigabytes of data > the third party tool had stored in many directories. Of course I don't > know, but I'd guess that someone with little experience was tasked with the > integration with solr at the third party software company and they followed > some examples... then turned them into an "integration" blissfully unaware > of the limitations of what they had done. > > I just re-read the ref guide page on post tool > <https://solr.apache.org/guide/8_8/post-tool.html>, and there's nothing > there to indicate to the reader that this might not be a good production > level solution. Also I notice a couple of recent Jira issues regarding > handling of corner cases of strange (broken) behavior or content in a web > site's response, giving the impression that that user (who reported both > issues) might be treading a path that will stretch the bounds of what the > post tool can/should be relied upon for. > > https://issues.apache.org/jira/browse/SOLR-15381 > https://issues.apache.org/jira/browse/SOLR-15370 > > How do folks feel about adding a warning or info box at the top of post > tool docs indicating that it is not meant as a production solution, only as > a quick way to test out documents. We might also say something more > concrete like "virtually any use for a corpus containing over a few > thousand documents is a bad idea"? ... or something like that, suggestions > welcome... > > If folks agree then it seems that these two issues are likely to be > WONTFIX. > > -Gus > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > > > > _______________________ > *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467 > | 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. > >
