Hi, I've never heard the complaint that Solr is hard to use. To the contrary, most people I come across have downloaded Solr themselves, walked through the tutorial and praise the simplicity with which they can start indexing and searching content.
When they come to us asking for consultancy or training, they are already in love with the product, they use it but realize that great search is so much more than just getting the HTTP requests or XML right. So while any "average Java developer" will be able to download and use Solr within an hour or two (my statement - even PHP developers can do that :-) ), that's just the beginning of it all. With your reasoning, all software for which training classes exist are bad and hard to use. Our training classes do not focus on the technology itself, but best practices to achieve good search user experience *using* Solr. This is a skill not even seasoned SQL developers have. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 15. juni 2013 kl. 21:39 skrev Jack Krupansky <j...@basetechnology.com>: > [My apologies to Roland for "hijacking" his original thread for this rant! > Look what you started!!] > > And I will stand by my statement: "Solr is too much of a beast for average > app developers to master." > > And the key word there, in case a too-casual reader missed it is "master" - > not "use" in the sense of hack something together or solving a niche > application for a typical Solr deployment, but master in the sense of having > a high level of confidence about the vast bulk (even if not absolutely 100%) > of the subject matter, Solr itself. > > I mean, generally, on average what percentage of Solr's many features has > the average Solr app-deployer actually "mastered"? > > And, what I am really referring to is not what expertise the pioneers and > "expert" Solr solution consultants have had, but the level of expertise > required for those who are to come in the years ahead who simply want to > focus on their application without needing to become a "Solr expert" first. > > The context of my statement was the application "devs" referenced earlier in > this thread who were struggling because the Solr API was not 100% pure > RESTful. As the respondent indicated, they were much happier to have a > cleaner, more RESTful API that they as app developers can deal with, so that > they wouldn't have to "master" all of the bizarre inconsistencies of Solr > itself (e.g., just the knowledge that SolrCell doesn't support partial/atomic > update.) > > And, the real focus of my statement, again in this particular context" is the > actual application devs, the guys focused on the actual application subject > matter itself, not the "Solr Experts" or "Solr solution architects" who do > have a lot higher mastery of Solr than the "average" application devs. > > And if my statement were in fact false, questions such as began this thread > would never have come up. The level of traffic for Solr User would be > essentially zero if it were really true that average application developers > can easily "master" Solr. > > And there would be zero need so many of these Solr training classes if Solr > were so easy to "master". In fact, the very existence of so many Solr > training classes effectively proves my point. And that's just for "basic" > Solr, not any of the many esoteric points such as at the heart of this > particular thread (i.e., SolrCell not supporting partial/atomic update.) > > And, in conclusion, my real interest is in helping the many "average" > application developers who post inquiries on this Solr user list for the > simple reason that they ARE in fact "struggling" with Solr. > > Personally, I would suggest that a typical (average) successful deployer of > Solr would be more readily characterized as having "survived" the Solr > deployment process rather than having achieved a truly deep "mastery" of > Solr. They may have achieved confidence about exactly what they have > deployed, but do they also have great confidence that they know exactly what > will happen if they make slight and subtle changes or what exactly the fix > will be for certain runtime errors? For the "average application developer" > I'm talking about, not the elite expert Solr consultants. > > One final way of putting it. If a manager or project leader wanted to staff a > dev position to be "in-house Solr expert", can they just hire any old average > Java programmer with no Solr experience and expect that he will rapidly > "master" Solr? > > I mean, why would so many recruiters be looking for a "Solr expert" or > engaging the services of Solr sonsultancies if mastery of Solr by "average > application developers" was a reality?! > > [I want to hear Otis' take on this!] > > -- Jack Krupansky > > -----Original Message----- From: Grant Ingersoll > Sent: Saturday, June 15, 2013 1:47 PM > To: solr-user@lucene.apache.org > Subject: Re: Adding pdf/word file using JSON/XML > > > On Jun 15, 2013, at 12:54 PM, Alexandre Rafalovitch <arafa...@gmail.com> > wrote: > >> On Sat, Jun 15, 2013 at 10:35 AM, Grant Ingersoll <gsing...@apache.org> >> wrote: >>> That being said, it truly amazes me that people were ever able to implement >>> Solr, given some of the FUD in this thread. I guess those tens of >>> thousands of deployments out there were all done by above average devs... >> >> I would not classify the thread as FUD. > > I was just referring to the part about how Solr isn't something average devs > can do, which I think is FUD. > > At any rate, I think the ExtractingReqHandler could be updated to allow for > metadata, etc. to be passed in with the raw document itself and a patch would > be welcome. It's something the literals stand in for now as a lightweight > proxy, but clearly there is an opportunity for more to be passed in.=
