[
https://issues.apache.org/jira/browse/LUCENE-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved LUCENE-1838.
-
Resolution: Fixed
r806885
> BoostingNearQuery must implement clone - now it clones t
[
https://issues.apache.org/jira/browse/LUCENE-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated LUCENE-1838:
Attachment: LUCENE-1838.patch
> BoostingNearQuery must implement clone - now it clones t
aels fail stack trace I see that these
payload queries should also implement toString(). I'll roll into this patch.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span co
6 AM:
---
adds clone - made SpanNearQuery internals protected.
*edit*
Adds QueryUtils.check back too, it will pass now with the clone.
was (Author: markrmil...@gmail.com):
adds clone - made SpanNearQuery internals protected.
> BoostingNearQuery must implement clone - now it clon
.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span container classes
> --
>
> Key: LUCENE-1838
>
fixed in
LUCENE-1838
> BoostingNearQuery doesn't have hashCode/equals
> --
>
> Key: LUCENE-1830
> URL: https://issues.apache.org/jira/browse/LUCENE-1830
> Project: Lucene - Jav
investigating two issues at once - popped the QueryUtils
test back in (it was originally missing) thinking it worked with this
hashCode/equals, but it catches something. My bad.
> BoostingNearQuery doesn't have hashCod
have screwed something up ... I'll fix it.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span co
.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
{noformat}
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span contain
into trouble with Querys and cloning.
BooleanQuery, DisjunctionQuery have quite a reliance on it - as do the
SpanQueries (all in rewrite). Improperly cloning can sometimes have extra
special effects with MultiSearcher : LUCENE-1599
> BoostingNearQuery must implement clone - now it clon
e/equals/clone check.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span container classes
> --
>
>
efault to true) q1.class == q1.class test
to the QueryUtils hashCode/equals/clone check.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span co
ract clone so that SpanQuerys are
required to implement cloneable.
> BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
> cloning is required for Span contain
BoostingNearQuery must implement clone - now it clones to a NearSpanQuery -
cloning is required for Span container classes
--
Key: LUCENE-1838
[
https://issues.apache.org/jira/browse/LUCENE-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved LUCENE-1830.
-
Resolution: Fixed
r806591
> BoostingNearQuery doesn't have hashCod
base class to
enforce they they are properly implemented in subclasses.
> BoostingNearQuery doesn't have hashCode/equals
> --
>
> Key: LUCENE-1830
> URL: https://issues.apache.org/jir
Grant Ingersoll wrote:
>
> On Aug 20, 2009, at 3:39 PM, Mark Miller wrote:
>
>> In a similar line though, BoostingFunctionTermQuery doesn't really fit
>> with BoostingNearQuery. I see part of why its not called
>> BoostingTermQuery is because BoostingTermQuery is d
On Aug 21, 2009, at 8:23 AM, Mark Miller wrote:
Grant Ingersoll wrote:
On Aug 20, 2009, at 3:44 PM, Mark Miller wrote:
And what is the purpose of the marker interface PayloadQuery?
Is there a use case for this?
At the time I was adding it, I was thinking about adding a Payload
query that
On Aug 20, 2009, at 3:39 PM, Mark Miller wrote:
In a similar line though, BoostingFunctionTermQuery doesn't really fit
with BoostingNearQuery. I see part of why its not called
BoostingTermQuery is because BoostingTermQuery is deprecated - but why
can't the BoostingFunctionTerm
Grant Ingersoll wrote:
>
> On Aug 20, 2009, at 3:44 PM, Mark Miller wrote:
>
>> And what is the purpose of the marker interface PayloadQuery?
>>
>> Is there a use case for this?
>
> At the time I was adding it, I was thinking about adding a Payload
> query that took in other Payload queries, i.e. s
On Aug 20, 2009, at 3:44 PM, Mark Miller wrote:
And what is the purpose of the marker interface PayloadQuery?
Is there a use case for this?
At the time I was adding it, I was thinking about adding a Payload
query that took in other Payload queries, i.e. something like:
CoolNewQuery(Paylo
BoostingNearQuery doesn't have hashCode/equals
--
Key: LUCENE-1830
URL: https://issues.apache.org/jira/browse/LUCENE-1830
Project: Lucene - Java
Issue Type: Bug
Components: S
And what is the purpose of the marker interface PayloadQuery?
Is there a use case for this?
- Mark
Mark Miller wrote:
> In a similar line though, BoostingFunctionTermQuery doesn't really fit
> with BoostingNearQuery. I see part of why its not called
> BoostingTermQu
In a similar line though, BoostingFunctionTermQuery doesn't really fit
with BoostingNearQuery. I see part of why its not called
BoostingTermQuery is because BoostingTermQuery is deprecated - but why
can't the BoostingFunctionTermQuery impl replace BoostingTermQuery with
average as t
, 2009 at 8:21 PM, Michael
> McCandless wrote:
>
>> +1
>>
>> Mike
>>
>> On Thu, Aug 20, 2009 at 11:08 AM, Mark Miller wrote:
>>
>>> BoostingNearQuery averages payloads - shouldn't it take a
>>> Payload
+1
On Thu, Aug 20, 2009 at 8:21 PM, Michael
McCandless wrote:
> +1
>
> Mike
>
> On Thu, Aug 20, 2009 at 11:08 AM, Mark Miller wrote:
>> BoostingNearQuery averages payloads - shouldn't it take a
>> PayloadFunction as well?
>>
>> --
>
+1
Mike
On Thu, Aug 20, 2009 at 11:08 AM, Mark Miller wrote:
> BoostingNearQuery averages payloads - shouldn't it take a
> PayloadFunction as well?
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> -
BoostingNearQuery averages payloads - shouldn't it take a
PayloadFunction as well?
--
- Mark
http://www.lucidimagination.com
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e
801667. thanks Peter!
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
> Is
sumPayloads more generic and protected, so that one could override it
and do other things besides sum.
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/bro
[
https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated LUCENE-1341:
Fix Version/s: (was: 3.0)
2.9
> BoostingNearQuery class (protot
)
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Qu
date? I think this could go into 2.9 if you
can do so fairly quickly.
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
>
[
https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keegan updated LUCENE-1341:
-
Attachment: lucene-1341-new-1.patch
As I was debugging a unit test for BoostingNearQuery, I
k it just needs some unit tests and then it will be good.
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
onths late because I missed Grant's e-mail requesting me to retest. I
was just recently looking to see what became of the original patch.
Peter
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
>
: (was: 2.4)
3.0
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
> Is
the BNQ to the
payloads package.
Peter, we need tests before this can be committed.
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
>
: (was: 2.3.2)
2.4
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
> Is
[
https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-1341:
---
Assignee: Grant Ingersoll
> BoostingNearQuery class (protot
1.4
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
> Issue Type: Improvement
> C
5004
#action_12615004 ]
Peter Keegan commented on LUCENE-1341:
--
Note that this patch requires java 1.5 or later (easily modified to
run on 1.4)
BoostingNearQuery class (prototype)
---
Key: LUCENE-
5 or later (easily modified to run on 1.4)
> BoostingNearQuery class (prototype)
> ---
>
> Key: LUCENE-1341
> URL: https://issues.apache.org/jira/browse/LUCENE-1341
> Project: Lucene - Java
>
[
https://issues.apache.org/jira/browse/LUCENE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Keegan updated LUCENE-1341:
-
Attachment: BoostingNearQuery.java
bnq.patch
> BoostingNearQuery cl
BoostingNearQuery class (prototype)
---
Key: LUCENE-1341
URL: https://issues.apache.org/jira/browse/LUCENE-1341
Project: Lucene - Java
Issue Type: Improvement
Components: Query/Scoring
Affects
45 matches
Mail list logo
