On Jan 15, 2006, at 3:34 PM, Robert Kirchgessner wrote:
There was even a patch to that problem:
http://issues.apache.org/jira/browse/LUCENE-211
This is a large and somewhat hard-to-read patch. Some stuff looks
familiar. Looks like he's concatenating fieldname along with
tokentext, whic
Hi,
I've tried to summarize the discussion so far:
My proposal was to move the tokenized/binary/compressed
bits from *.fdt (field values) to *.fnm (field definitions). That
would make the intent of the code handling field attributes
much clearer and reduce the complexitiy of the code.
(you'll fi
> I don't really understand the low level fileformat details of lucene (I
> let Yonik worry abotu those things for me) and I've already forgotten the
> details from earlier in this thread of what field properties on a per
> field basis and which are stored on a per document basis -- but as someone
Hello Marvin,
> Those are the easy ones. There's more, but it would require a major
> rewrite. If you're interested, perform a websearch for '"KinoSearch
> Merge Model"' to find the previous post I sent to this list on the
> subject.
I did it, thank you. As you write in your explanation of Kino
: 1.) We now have DateField and DateTools which use different formats. So
: QueryParser needs to know which one has been used during indexing. I've a
: local patch that adds an appropriate set... method.
A much as i dislike the "standard" mechanism for indexing Dates, I'm of
the opinion that if p
Hi,
QueryParser can parse input like [01.01.2005 TO 15.01.2005] if the German
locale is activated ("01.01.2005" is the way 2005-01-01 is usually written
in Germany). By "can parse" I mean that the date is recognized and
automatically turned into the format used by DateField (like "0e9eodds0").
: Option 1: Merge field definitions at the segment level rather than
: the Document level. The defs stay stored with individual segments,
: but everything gets moved into the .fnm file, including
: IS_COMPRESSED, IS_BINARY, etc (as I believe Robert was proposing).
:
: Option 2: Centralize the field
Hello Hoss,
On Jan 15, 2006, at 12:59 AM, Chris Hostetter wrote:
: IMO, there's no reason to allow field definitions to be spec'd more
: often than once per IndexWriter. Need to add a new field for docs
: 501-1000 of a 1000-doc indexing pass? No problem: create a new
: IndexWriter, define new
: IMO, there's no reason to allow field definitions to be spec'd more
: often than once per IndexWriter. Need to add a new field for docs
: 501-1000 of a 1000-doc indexing pass? No problem: create a new
: IndexWriter, define new fields, and you're off and running.
If I understand your argument,
