Hey Kevin, thanks for the reply - Going down the road of recoding most of it was exactly what I wanted to avoid.. I did go ahead and submit a JIRA issue/patch that addresses this. I think this patch makes the whole thing much simpler and exposes some of the powerful underlying mechanisms in a pretty standard way. Feel free to check it out/comment, JIRA-1149
-Chak Kevin Osborn-2 wrote: > > I had a case where I was extending the DisMax parser. So, my class > MyNewDxMaxQParserPlugin extends QParserPlugin. But, I just copied and > pasted from DixMaxQParserPlugin.java. Sure, doesn't reuse all the code, > but in my case I just needed the existing code as an example and then I > had to change it in a few places. Rather than dealing with inheritence, > etc., it was simpler to just contol the code on my own. > > > > > ________________________________ > From: KaktuChakarabati <jimmoe...@gmail.com> > To: solr-dev@lucene.apache.org > Sent: Wednesday, May 6, 2009 4:22:56 PM > Subject: Creating a new QParserPlugin > > > (Forwarded from solr-users, I figured its more appropriate here.. ) > > Hello everyone, > I am trying to write a new QParserPlugin+QParser, one that will work > similar > to how DisMax does, but will give me more control over the > FunctionQuery-related part of the query processing (e.g in regards to a > specified bf parameter). > > In specific, I want to be able to affect the way the queryNorm (and > possibly > other factors) interact with a > pre-computed value I store in a static field (i.e I compute an index-time > score for a document that I wish to use in a bf as a ValueSource, without > being affected by queryNorm or other such extranous considerations.) > > While trying this, I notice I run alot into cases where some parts I try > to > override/inherit from are private to a java package namespace, and this > makes the whole thing very cumbersome. > > Examples for this are the DismaxQParser class which is defined as a local > class inside the DisMaxQParserPlugin.java file (i think this is bad > practice > - otherwise, FunctionQParserPlugin/FunctionQParser do have their own > seperate files, so i think this is a good convention to follow generally). > Another case is where i try to inherit from FunctionQParser and end up not > being able to replicate some of the parse() logic, because it uses the > QueryParsing.StrParser class which is a static inner class and so is only > accessible from the solr.search namespace. > > In short, many such cases seem to arise and i think this poses a > considerable limitation on > the possibilities of extending solr. > > Otherwise, if some of you have some notions about going about what i'm > trying to do differently, > I would be happy to hear. > > Thanks, > -Chak > -- > View this message in context: > http://www.nabble.com/Creating-a-new-QParserPlugin-tp23417409p23417409.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > > > -- View this message in context: http://www.nabble.com/Creating-a-new-QParserPlugin-tp23417409p23436807.html Sent from the Solr - Dev mailing list archive at Nabble.com.
