Serious thread hiJacking here........ Hey, why was I singled out? ;)
I don't have time to get deep into this (there are non-experts I need to help! kidding...) , but I'll say this: * Do you know any non-trivial piece of software in which an average developer is a master? I've managed to master the `man' command! * How about life? Have the average people mastered it? I know I'm faaaaar from it. How about you? :) Solr is larger than life, so why would it be any different? * Jack, once your book is out, maybe the road to Solr mastery will be just a Solr Bible away! * Patches welcome :) Joking aside, Solr is non-trivial, but I think an average can get. It's not rocket science. Otis -- Solr & ElasticSearch Support -- http://sematext.com/ <== experts inside ;) On Sat, Jun 15, 2013 at 3:39 PM, Jack Krupansky <j...@basetechnology.com> wrote: > [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.=