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 thread
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 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
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
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
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
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
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
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 was
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
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
FWIW, I can make Tuesday but not Monday.
Doug
Yonik Seeley wrote:
Solr has just graduated from the Incubator, and has been accepted as a
Lucene sub-project!
Congratulations and welcome!
Doug
Some good press for several Lucene projects!
http://news.yahoo.com/s/cmp/20061122/tc_cmp/195600041
Doug
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 current index
behavior
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
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
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
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
19 matches
Mail list logo
