question on design for ordering of field names written to FieldInfos object

[Peter M Cipollone <lu...@bihvhar.com>]

(I accidentally sent this to the Users' list first)

Hi,

I have a question about the following code from
org.apache.lucene.index.SegmentMerger.  I would like to know if the ordering
of the fields as they are stored to the FieldInfos object is critical to
some other purpose.

In the code below (from a week+/- ago CVS pull), the fields are stored in
the following order:
1. fields indexed=true, termVectors=true
2. fields indexed=true, termVectors=false
3. fields stored=true, indexed=false

The reason I ask is because I am working on some functionality that will
require the order of fields to be immutable across merges.  At present
FieldInfos are created in two ways, one from a Document as it is merged into
an index, and again when index segments are merged.  They use two different
ordering mechanisms.

Thanks for your help.
Pete

private final int mergeFields() throws IOException {
    fieldInfos = new FieldInfos();    // merge field names
    int docCount = 0;
    for (int i = 0; i < readers.size(); i++) {
      IndexReader reader = (IndexReader) readers.elementAt(i);
1.      fieldInfos.addIndexed(reader.getIndexedFieldNames(true), true);
2.      fieldInfos.addIndexed(reader.getIndexedFieldNames(false), false);
3.      fieldInfos.add(reader.getFieldNames(false), false);
    }
    fieldInfos.write(directory, segment + ".fnm");


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Simple patch for broken link in javadoc of Weight.java

[Paul Elschot <pa...@xs4all.nl>]

Regards,
Paul


Index: search/Weight.java
===================================================================
RCS file: /home/cvspublic/jakarta-lucene/src/java/org/apache/lucene/search/Weight.java,v
retrieving revision 1.3
diff -u -r1.3 Weight.java
--- search/Weight.java	29 Mar 2004 22:48:04 -0000	1.3
+++ search/Weight.java	26 Jul 2004 16:55:40 -0000
@@ -25,7 +25,7 @@
  * <p>A Weight is constructed by a query, given a Searcher ({@link
  * Query#createWeight(Searcher)}).  The {@link #sumOfSquaredWeights()} method
  * is then called on the top-level query to compute the query normalization
- * factor (@link Similarity#queryNorm(float)}).  This factor is then passed to
+ * factor {@link Similarity#queryNorm(float)}.  This factor is then passed to
  * {@link #normalize(float)}.  At this point the weighting is complete and a
  * scorer may be constructed by calling {@link #scorer(IndexReader)}.
  */


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org

Re: question on design for ordering of field names written to FieldInfos object

[Doug Cutting <cu...@apache.org>]

Peter M Cipollone wrote:
> I have a question about the following code from
> org.apache.lucene.index.SegmentMerger.  I would like to know if the ordering
> of the fields as they are stored to the FieldInfos object is critical to
> some other purpose.
> 
> In the code below (from a week+/- ago CVS pull), the fields are stored in
> the following order:
> 1. fields indexed=true, termVectors=true
> 2. fields indexed=true, termVectors=false
> 3. fields stored=true, indexed=false

I don't think it is critical to any other purpose, but nor do I think 
one should require these to always be ordered the same way without a 
very good reason.  They didn't used to be ordered this way, and 
implementations of Lucene in other language might order them differently.

Doug



---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org