Hi Paul:
Thanks for the reply.
The problem is that I want to use QueryParser to construct the
query for me. I am having to overriding the logic in QueryParser to
construct my own derived class, which seems to me like a convoluted
way to just setting the Similariy.
-John
On Nov 11, 2007 12:50 PM, Paul Elschot <[EMAIL PROTECTED]> wrote:
> On Sunday 11 November 2007 18:28:09 John Wang wrote:
> > Anyone has comments on this one or should I forward this to the user list?
>
> An inline subclass overriding Query.getSimilarity() to have a Query
> use another Similarity worked for me.
>
> Regards,
> Paul Elschot
>
>
>
> > thanks
> >
> > -John
> >
> > On 11/8/07, John Wang <[EMAIL PROTECTED]> wrote:
> > > It would be cleaner if we can add some sort of factory pattern for
> > > similarities to Query. It is essentially using the Searcher as the
> > > source for Similarity.
> > >
> > > Thoughts?
> > >
> > > -john
> > >
> > > On Nov 8, 2007 9:37 AM, John Wang <[EMAIL PROTECTED]> wrote:
> > > > Hi:
> > > >
> > > > We are running into a situation that we want to have a similarity
> > > > depending on a field.
> > > >
> > > > We also want to leverage QueryParser. The easiest thing we can find
> > > > is to override the QueryParser class with the method getFieldQuery. It
> > > > would be a lot simpler if we can just set the similarity on the
> > > > returned field.
> > > >
> > > > It would involve adding the setter on the Query class.
> > > >
> > > > Any thoughts? I can create a jira issue if it is something kosher to
> > >
> > > do.
> > >
> > > > Thanks
> > > >
> > > > -John
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
