You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Simon Willnauer <si...@googlemail.com> on 2011/01/10 11:59:31 UTC
Consolidating FunctionQuery
hey,
today I came across function query in lucene and that reminded me that
Solr is already using its own derived version which is no good IMO. We
should try to consolidate the two version and make solr use the
consolidated version which would even be good for lucene users. It
seems it would make lots of sense to make the entire function query
stuff a module and drop it from core in 4.0. I didn't look too close
into the solr version but it seems to be not that hard to luceneify it
and move it to modules, thoughts?
simon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidating FunctionQuery
Posted by Doron Cohen <cd...@gmail.com>.
On Mon, Jan 10, 2011 at 2:13 PM, Simon Willnauer <
simon.willnauer@googlemail.com> wrote:
> So moving stuff to modules has several advantages compared to trunk. I
> think we all agree that we want lucene to be able to make use of this
> functinality right?! So if we keep it in core we can either try to
> make it right this time or we stick with bw compat for a long time
> again risking that the same thing happens again and solr changes stuff
> in incompatible ways. While this is a minor risk, I see FQ not really
> a core part of lucene but rather something that is similar to
> Analysis, a package with a small base interface (which could stay in
> lucene core) and a large useful impl base like all the funcs in solr.
> So it seems to me that modules is the right place for at least those
> implemenations.
>
> does that make sense?
>
Do you mean that modules are not subject to backcompat guidelines? I was not
ware of that.
Relieving backcompat burden is a motivation by itself, but that asside,
function query (or custom score query) seems like basic capability to me -
it is not something that both Lucene and Solr are using, but rather
something that Lucene is providing and Solr and user applications are using,
right?
Re: Consolidating FunctionQuery
Posted by Simon Willnauer <si...@googlemail.com>.
On Mon, Jan 10, 2011 at 12:56 PM, Doron Cohen <cd...@gmail.com> wrote:
> +1 for having a single function query - actually this is what LUCENE-1081
> and SOLR-192 is about. I'd look at this after LUCENE-1812, but this is
> waiting so long now, please go ahead with this, I'll follow/join.
good stuff...
>
> -0 for moving function to modules - I think this is used as core capability
> by many applications/users and I don't see why it should be in modules, as
> to me this is more like .. I was going to say "like payloads" but this is
> not true, it is not nearly as involved and as internal as payloads, so
> replaced "-1" with "-0" here, but, could you explain why move this from core
> to modules?
So moving stuff to modules has several advantages compared to trunk. I
think we all agree that we want lucene to be able to make use of this
functinality right?! So if we keep it in core we can either try to
make it right this time or we stick with bw compat for a long time
again risking that the same thing happens again and solr changes stuff
in incompatible ways. While this is a minor risk, I see FQ not really
a core part of lucene but rather something that is similar to
Analysis, a package with a small base interface (which could stay in
lucene core) and a large useful impl base like all the funcs in solr.
So it seems to me that modules is the right place for at least those
implemenations.
does that make sense?
>
> Doron
>
> On Mon, Jan 10, 2011 at 1:03 PM, Chris Male <ge...@gmail.com> wrote:
>>
>> +1 to this idea.
>> I recall talking to Robert and Mark about it as a good first step as part
>> of the spatial code consolidation as well.
>>
>> On Mon, Jan 10, 2011 at 11:59 PM, Simon Willnauer
>> <si...@googlemail.com> wrote:
>>>
>>> hey,
>>>
>>> today I came across function query in lucene and that reminded me that
>>> Solr is already using its own derived version which is no good IMO. We
>>> should try to consolidate the two version and make solr use the
>>> consolidated version which would even be good for lucene users. It
>>> seems it would make lots of sense to make the entire function query
>>> stuff a module and drop it from core in 4.0. I didn't look too close
>>> into the solr version but it seems to be not that hard to luceneify it
>>> and move it to modules, thoughts?
>>>
>>> simon
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Chris Male | Software Developer | JTeam BV.| www.jteam.nl
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Consolidating FunctionQuery
Posted by Doron Cohen <cd...@gmail.com>.
+1 for having a single function query - actually this is what LUCENE-1081
and SOLR-192 is about. I'd look at this after LUCENE-1812, but this is
waiting so long now, please go ahead with this, I'll follow/join.
-0 for moving function to modules - I think this is used as core capability
by many applications/users and I don't see why it should be in modules, as
to me this is more like .. I was going to say "like payloads" but this is
not true, it is not nearly as involved and as internal as payloads, so
replaced "-1" with "-0" here, but, could you explain why move this from core
to modules?
Doron
On Mon, Jan 10, 2011 at 1:03 PM, Chris Male <ge...@gmail.com> wrote:
> +1 to this idea.
>
> I recall talking to Robert and Mark about it as a good first step as part
> of the spatial code consolidation as well.
>
>
> On Mon, Jan 10, 2011 at 11:59 PM, Simon Willnauer <
> simon.willnauer@googlemail.com> wrote:
>
>> hey,
>>
>> today I came across function query in lucene and that reminded me that
>> Solr is already using its own derived version which is no good IMO. We
>> should try to consolidate the two version and make solr use the
>> consolidated version which would even be good for lucene users. It
>> seems it would make lots of sense to make the entire function query
>> stuff a module and drop it from core in 4.0. I didn't look too close
>> into the solr version but it seems to be not that hard to luceneify it
>> and move it to modules, thoughts?
>>
>> simon
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Chris Male | Software Developer | JTeam BV.| www.jteam.nl
>
Re: Consolidating FunctionQuery
Posted by Chris Male <ge...@gmail.com>.
+1 to this idea.
I recall talking to Robert and Mark about it as a good first step as part of
the spatial code consolidation as well.
On Mon, Jan 10, 2011 at 11:59 PM, Simon Willnauer <
simon.willnauer@googlemail.com> wrote:
> hey,
>
> today I came across function query in lucene and that reminded me that
> Solr is already using its own derived version which is no good IMO. We
> should try to consolidate the two version and make solr use the
> consolidated version which would even be good for lucene users. It
> seems it would make lots of sense to make the entire function query
> stuff a module and drop it from core in 4.0. I didn't look too close
> into the solr version but it seems to be not that hard to luceneify it
> and move it to modules, thoughts?
>
> simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Chris Male | Software Developer | JTeam BV.| www.jteam.nl
Re: Consolidating FunctionQuery
Posted by Grant Ingersoll <gs...@apache.org>.
On Jan 10, 2011, at 5:59 AM, Simon Willnauer wrote:
> hey,
>
> today I came across function query in lucene and that reminded me that
> Solr is already using its own derived version which is no good IMO. We
> should try to consolidate the two version and make solr use the
> consolidated version which would even be good for lucene users. It
> seems it would make lots of sense to make the entire function query
> stuff a module and drop it from core in 4.0. I didn't look too close
> into the solr version but it seems to be not that hard to luceneify it
> and move it to modules, thoughts?
Much of the function query stuff in Solr is driven off of query parsers that support the functions as well as the FieldType, which is one of the reasons Lucene has never had much support. I think the other reason is simply that in Lucene it's often not difficult to get "function-like" capabilities without the formality of a function query (since one is writing lower-level code). On the other hand, it has always amazed me at how much Solr user's use FQs (function queries) and how little Lucene users use them.
At either rate, +1 on it being a module if you can manage to detangle it all (there is a lot of coupling with FieldTypes, I suspect) without reducing the functionality.
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org