[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549429
]
Grant Ingersoll commented on LUCENE-1083:
-
Thanks, Matt. I assume the antjdiff.jar needs to be included
[
https://issues.apache.org/jira/browse/LUCENE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1082.
Resolution: Fixed
Fix Version/s: 2.3
I just committed this. Thanks Alan!
Yeah, I wasn't too excited over it and I certainly didn't lose any
sleep over it, but there are some interesting things of note in there
concerning Lucene, including the claim that it fell over on indexing
WT10g docs (page 40) and I am always looking for ways to improve
things. Overall, I
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549500
]
Doug Cutting commented on LUCENE-1083:
--
The prior release is a new concept that needs to be added to the build
: In general I would agree that people may want different implementations for
: compare(), but I hardly see that's the case for ScoreDoc. After all, you can
: either compare it by score or by doc (at least now). I believe that since
: most people use the TopDocsHitCollector, they prefer the
In general I would agree that people may want different implementations for
compare(), but I hardly see that's the case for ScoreDoc. After all, you can
either compare it by score or by doc (at least now). I believe that since
most people use the TopDocsHitCollector, they prefer the
Did it crash on the 10 GB? I thought it said that it just took way to
long (7 times the best or something). Frankly, either case is suspect.
Last summer I indexed about 5 million docs with a total size at the
*very* least of 10 GB on my 3 year old desktop. It didn't take much more
than 8 hours
All true and good points. Lucene held up quite nicely in the search
aspect (at least perf. wise) and I generally don't think making these
kinds of comparisons are all that useful (we call it apple and oranges
in English :-) ).
What I am trying to get at is if this paper was just about
There is an expression in French that says comparer des pommes et des
poires which literally means to compare apples and pears. That's what
this paper is about. For my point of view, such a comparison would be
interesting only if a cross analysis of different criterions (for example,
retrieval
increase default maxFieldLength?
Key: LUCENE-1084
URL: https://issues.apache.org/jira/browse/LUCENE-1084
Project: Lucene - Java
Issue Type: Improvement
Components: Index
Affects Versions: 2.2
Yes, and even if they did not use the stock defaults, I would bet there
would be complaints about what was done wrong at every turn. This seems
like a very difficult thing to do. How long does it take to fully learn
how to correctly utilize each search engine for the task at hand? I am
sure
There is a good chance that they were using stock indexing defaults,
based on:
Lucene:
In the present work, the simple applications
bundled with the library were used to index the collection.
On 7-Dec-07, at 10:27 AM, Grant Ingersoll wrote:
Yeah, I wasn't too excited over it and I
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549526
]
Matt Doar commented on LUCENE-1083:
---
As an aside, Maven repositories in general could usefully be enhanced to
[
https://issues.apache.org/jira/browse/LUCENE-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549475
]
Matt Doar commented on LUCENE-1083:
---
Grant,
I was imagining more that the release process for Lucene could be
14 matches
Mail list logo
