You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by KaktuChakarabati <ji...@gmail.com> on 2009/05/07 01:22:56 UTC
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.
Re: Creating a new QParserPlugin
Posted by KaktuChakarabati <ji...@gmail.com>.
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 <ji...@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.
Re: Creating a new QParserPlugin
Posted by Kevin Osborn <os...@yahoo.com>.
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 <ji...@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.