Ryan McKinley wrote:
In order to get spatial lucene into solr, we need to figure out how to
fix the memory leak described in:
https://issues.apache.org/jira/browse/LUCENE-1304
Reading the posts on LUCENE-1304, it seems to point to LUCENE-1483 as
the _real_ solution while LUCENE-1304 would just
[
https://issues.apache.org/jira/browse/LUCENE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688494#action_12688494
]
Mark Miller commented on LUCENE-1570:
-
Yonik spit out a bit of a better answer while I
[
https://issues.apache.org/jira/browse/LUCENE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688486#action_12688486
]
Mark Miller commented on LUCENE-1570:
-
I've wanted this in the past. Its certainly pos
[
https://issues.apache.org/jira/browse/LUCENE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688482#action_12688482
]
Yonik Seeley commented on LUCENE-1570:
--
This is pretty easy to implement by overridin
In order to get spatial lucene into solr, we need to figure out how to
fix the memory leak described in:
https://issues.apache.org/jira/browse/LUCENE-1304
Reading the posts on LUCENE-1304, it seems to point to LUCENE-1483 as
the _real_ solution while LUCENE-1304 would just be a deprecated ban
QueryParser.setAllowLeadingWildcard could provide finer granularity
---
Key: LUCENE-1570
URL: https://issues.apache.org/jira/browse/LUCENE-1570
Project: Lucene - Java
Issue Type
Let me give an example to explain my idea - I'm using dates in my
example, because it's easier to imagine :)
Let's say we have the following posting lists. There are 20 docs in the
index and an X means that a doc contains the corresponding term:
JanX X
Feb XX X
Mar
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688454#action_12688454
]
Michael McCandless commented on LUCENE-1522:
bq. I think this is an unrealisti
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688451#action_12688451
]
Michael Busch commented on LUCENE-1522:
---
{quote}
(Meaning, if you were to copy & pas
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688449#action_12688449
]
Mike Klaas commented on LUCENE-1561:
I agree that it is going to be almost impossible
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688448#action_12688448
]
Mark Miller commented on LUCENE-1522:
-
{quote}But that's really quite a serious proble
On 23-Mar-09, at 2:41 PM, Michael McCandless wrote:
I agree, but at least we need some clear criteria so the future
decision process is more straightforward. Towards that... it seems
like there are good reasons why something should be put into contrib:
* It uses a version of JDK higher than
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688439#action_12688439
]
Michael McCandless commented on LUCENE-1522:
bq. I think you are reading more
>> I think we are considering this for Lucene 3.0 (should be the
>> release after next) which will allow Java 1.5.
>
> So where are you going to put 1.6 and 1.7 contribs?
This is a good point: core Lucene must remain on "old" JREs, but we
should not force all contrib packages to do so.
> - contri
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688429#action_12688429
]
Eks Dev commented on LUCENE-1561:
-
maybe something along the lines:
usePureBooleanPosting
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688419#action_12688419
]
Mark Miller edited comment on LUCENE-1522 at 3/23/09 2:12 PM:
--
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688419#action_12688419
]
Mark Miller commented on LUCENE-1522:
-
I think you are reading more into that than I s
[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688409#action_12688409
]
Paul Elschot commented on LUCENE-1410:
--
The encoding in the google research slides is
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688408#action_12688408
]
Michael McCandless commented on LUCENE-1522:
Randomly searching in Google I ca
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688387#action_12688387
]
Michael McCandless commented on LUCENE-1561:
Naming is the hardest part!!
> M
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688385#action_12688385
]
Otis Gospodnetic commented on LUCENE-1561:
--
Might be good to keep a consistent na
On Mon, Mar 23, 2009 at 22:13, Mark Miller wrote:
> Earwin Burrfoot wrote:
>>>
>>> - contrib has always had a lower bar and stuff was committed under
>>> that lower bar - there should be no blanket promotion.
>>> - contrib items may have different dependencies... putting it all
>>> under the same
Earwin Burrfoot wrote:
- contrib has always had a lower bar and stuff was committed under
that lower bar - there should be no blanket promotion.
- contrib items may have different dependencies... putting it all
under the same source root can make a developers job harder
- many contrib items are l
> - contrib has always had a lower bar and stuff was committed under
> that lower bar - there should be no blanket promotion.
> - contrib items may have different dependencies... putting it all
> under the same source root can make a developers job harder
> - many contrib items are less related to
Are you arguing for no change Yonik? I agree with all of your points in
any case.
What appeals to me most so far is:
Take the best of contrib and up its status to something like "modules".
Equal to core, different requirements, dependencies, etc. Perhaps take
queryparser out of core, but fran
Shai Erera wrote:
> As a side comment, why not add setNextReader to HitCollector and
> then a getDocId(int doc) method which will do the doc + base
> arithmetic?
One problem is this breaks back compatibility on any current
subclasses of HitCollector.
Another problem is: not all collectors would
ok I missed 1483 completely.
As a side comment, why not add setNextReader to HitCollector and then a
getDocId(int doc) method which will do the doc + base arithmetic? I think
it's very easy for someone to forget to add that (+ base) to doc. You could
then just change TopDocCollector to call getDoc
[
https://issues.apache.org/jira/browse/LUCENE-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1555.
Resolution: Incomplete
Need more details here.
> Deadlock while optimize
> --
On Mon, Mar 23, 2009 at 11:10 AM, Michael McCandless
wrote:
> 4. Move contrib/* under src/java/*, updating the javadocs to state
> back compatibility promises per class/package.
- contrib has always had a lower bar and stuff was committed under
that lower bar - there should be no blanket
Michael Busch wrote:
>> And I don't think the sudden separation of "core" vs "contrib"
>> should be so prominent (or even visible); it's really a detail of
>> how we manage source control.
>
>> When looking at the website I'd like read that Lucene can do hit
>> highlighting, powerful query parsin
> If we're already creating a new TopScoreDocCollector (when was it
> added? I must have been dozing off while this happened...)
This was LUCENE-1483.
> How about if we introduce an abstract ScoringCollector (about the
> name later) which implements topDocs() and getTotalHits() and there
> will
[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688284#action_12688284
]
Eks Dev commented on LUCENE-1410:
-
It looks like Google went there as well (Block encoding
32 matches
Mail list logo
