I started a Lucene status page for July at:
http://wiki.apache.org/jakarta-lucene/Report-2005-07
Please help populate this page. It should contain news related to the
Lucene top-level project (not just the Java sub-project) since Lucene
became a top-level project at the beginning of this year
Greg Love wrote:
In the TheServerSide case study of the book, page 375, they say that
they close the IndexWriter and even point out that they did before
openning the IndexReader and deleting. So that kinda makes me wonder
if i'm safe having an IndexReader with deletions and and IndexWriter
with i
WolfgangTäger wrote:
While the search is carried out in a reasonably short time (about
500..800ms) we have a performance problem with actually retrieving the
documents by code like:
for (int i = nrhits-1; i >=0; i--){
Document hitDoc = hits.doc(i);
String code=hitDoc.get("code"
Paul Elschot wrote:
I'd like to raise an issue for lucene, but the lucene is not listed as a
project in the 'addressing' list for creating issues.
(lucene4c is listed there.)
I just fixed this.
Doug
I just ran accross a Ruby port of Lucene:
http://ferret.davebalmain.com/trac/
Doug
The 1.4.3 src distributions had been misplaced. Sorry. I just restored
them. They'll be on all of the Apache mirrors tomorrow.
Doug
sdamjad wrote:
But these one's dont contain src files
If i download them, then in src directory there is no directory for java
thanks
= Original Messa
The Lucene PMC has voted to add Yonik Seeley to its ranks.
Thanks, Yonik, for all you've done to advance the Lucene community!
Doug
Chris Hostetter wrote:
Spamming "general" so people on other subprojects besides java-user see
this...
http://wiki.apache.org/apachecon/BirdsOfaFeatherUs06
I'll be there!
Doug
James wrote:
We use Remote
ParalellMultiSearcher, with some custom modifications (and we are in the
process of making more) to allow most robust handling of many processes at
once and integration of the responses from various sub-indexes.
Can you share these modifications with others? If so, p
James wrote:
Let me check with the powers that be
here, and then get the code into a more polished form. We hope to have it
really enterprise-ready over the next couple months.
Great! Once you have permission, please post it sooner rather than
later, then others can help with polishing, or a
Chris Hostetter wrote:
: 3. If you're worried about high availability, then one fairly simple
: approach is to have two parallel set of search clusters, with a load
: balancer in front. For each cluster, monitor both the front-end
: server (where the results get combined) and each of the back-end
It seems that Nutch and Solr would benefit from a shared index serving
infrastructure. Other Lucene-based projects might also benefit from
this. So perhaps we should start a new project to build such a thing.
This could start either in java/contrib, or as a separate sub-project,
depending on
Yonik Seeley wrote:
On 10/18/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
We assume that, within an index, a file with a given name is written
only once.
Is this necessary, and will we need the lockless patch (that avoids
renaming or rewriting *any* files), or is Lucene's cu
Erik Hatcher wrote:
It's done frequently. In Lucene-land we have some committers that only
have rights to certain contrib sub-directories, for example. We could
easily do this for particular branches as well.
We actually have a set of contributors who only have access to the
entire contrib
Some good press for several Lucene projects!
http://news.yahoo.com/s/cmp/20061122/tc_cmp/195600041
Doug
Yonik Seeley wrote:
Solr has just graduated from the Incubator, and has been accepted as a
Lucene sub-project!
Congratulations and welcome!
Doug
Please don't use Lucene's mailing lists for job search. There are many
good job search engines out there (some powered by Lucene).
The sanctioned place for this is:
http://wiki.apache.org/jakarta-lucene/Support
Please feel free to add a link to that page.
Cheers,
Doug
Ning,
I am also interested in starting a new project in this area. The
approach I have in mind is slightly different, but hopefully we can come
to some agreement and collaborate.
My current thinking is that the Solr search API is the appropriate
model. Solr's facets are an important featur
[ No longer cross-posting to java-dev and solr-user. ]
Andrzej Bialecki wrote:
A particular client should be able to provide a consistent read/write
view by bonding to particular replicas of a shard. Thus a user who
makes a modification should be able to generally see that modification
in res
Steven A Rowe wrote:
Hmm, looking closer, I see that release 1.02 *was* referred to as 1.0.2 - see
Lucene's home page as of July 2002:
The last Sourceforge release was called "1.01b" and was created on
6/24/2001.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00136.html
FYI, Sourceforge
FWIW, I can make Tuesday but not Monday.
Doug
Grant Ingersoll wrote:
Therefore, it is with some hesitation that I suggest we mothball Lucy.
When committers are inactive for a year, we ask them if they'd like to
be made emeritus. Usually they either don't respond or they say yes.
If they say "no" we give them the benefit of the doubt for
Grant Ingersoll wrote:
I'd _suggest_ a few other things beyond just code commits, however:
+1 for all these.
Finally, six months or so does sound like the right time frame.
So we can consider this fair warning: if there have only been a few
token commits, and there isn't activity consisten
Marvin Humphrey wrote:
http://svn.apache.org/repos/asf/lucene/site/publish/images/logo.eps
Or, more simply:
http://lucene.apache.org/images/logo.eps
Doug
Michael McCandless wrote:
I think, in order to stop duplicating our analysis code across
Nutch/Solr/Lucene, we should separate out the analyzers into a
standalone package, and maybe as its own sub-project under the Lucene
tlp?
Is the goal to release these on a separate schedule from Lucene Java
Ted Dunning wrote:
Hadoop is a strange beast. The Hadoop core itself has fractured into three
projects that have independent mailing lists but which share release dates.
But without any releases yet. Is that "shared nothing"?
The rationale for the Hadoop split was that the single codebase wa
This question probably belongs on java-user@, not gene...@.
That said, coord() might be what you're looking for:
http://lucene.apache.org/java/3_0_1/api/core/org/apache/lucene/search/Similarity.html#coord%28int,%20int%29
Doug
tavi.nathanson wrote:
Hey everyone,
Let me start with an example q
Uwe Schindler wrote:
One idea: If we really make solr depend on the new lucene lib, solr
should not have lucene jars in its lib folder, but instead the
nightly build should fetch the jars from the lucene hudson build.
If Solr trunk is meant to always be based on Lucene trunk, then
shouldn't th
Otis Gospodnetic wrote:
Didn't we see Hadoop do
exactly the opposite? Doug described it as code-base being too big,
but I'd say the original list was also too high traffic (was split
into common-, hdfs-, and mapreduce- I believe).
The intent is that eventually HDFS and MapReduce will evolve
i
Mattmann, Chris A (388J) wrote:
Doesn't this move towards having a shared code base,
Yes. The desire seems to be to have a shared code base, no?
and more so the criteria for that of a TLP? Thoughts?
A shared codebase with a single pool of committers are canonical TLP
attributes, if that's
Grant Ingersoll wrote:
As
you've seen by the Board's indication, they only view that there
should be a single Lucene project. One committership, one project.
Or, two committerships, two projects. So, if the existing committer
structure were acceptable, then Solr would be split to a separate
On 06/14/2010 05:16 PM, Chris Hostetter wrote:
I'm having a hard time wrapping my head arround the idea of Lucy moving
from the Lucene TLP to the Incubator TLP. It probably would have made
sense for Lucy start in the Incubator years ago, but I'm not really sure
what value that would add now give
On 06/15/2010 10:48 AM, Mark Miller wrote:
Sounds like Doug is saying we should get a rough consensus from the PMC
on whether we want to put more effort into Lucy - not just abide its
existence as seems to have been the case.
Yes, but, to be clear, I don't think it's a huge effort, no more effo
On 04/11/2011 01:25 PM, entdeveloper wrote:
> Thanks Otis. And by your answer, does this mean that individual clauses in a
> boolean query are executed sequentially? not in parallel?
Clauses are executed in parallel. The execution of a conjunction is
able to efficiently skip occurrences in ranges
On 04/12/2011 08:53 AM, Yang wrote:
> when you say "executed" in parallel, could you please elaborate more
> on what "execute" refers to?
I mean that all matches for a query clause are not generally enumerated
before any results of its containing query are enumerated. There's
generally a single t
35 matches
Mail list logo
