Re: Consolidating FunctionQuery
+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 gento...@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.willna...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
Re: Consolidating FunctionQuery
On Mon, Jan 10, 2011 at 12:56 PM, Doron Cohen cdor...@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 gento...@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.willna...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Consolidating FunctionQuery
On Mon, Jan 10, 2011 at 2:13 PM, Simon Willnauer simon.willna...@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?
