Doug Cutting wrote:
It would be best to get the compiler to check the order.
If we change this, why not use type-safe enumerations:
http://www.javapractices.com/Topic1.cjp
The calls would look like:
new Field("name", "value", Stored.YES, Indexed.NO, Tokenized.YES);
Stored could be implemented as th
I think this is a great idea.
I've never used the Field.Keyword and Field.Text type methods because I
can never remember what their 3-boolean-argument equivalents are. I
always stick the constructor format in a comment somewhere and use it.
>>> Doug Cutting <[EMAIL PROTECTED]> 07/11/04 12:03PM >>
new Field("name", "value", STORED + TOKENIZED)
The constructor would break that down bitwise!
-Original Message-
From: Kevin A. Burton [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 11, 2004 5:05 AM
To: Lucene Users List
Subject: Field.java -> STORED, NOT_STORED, etc...
On Sunday 11 July 2004 10:03, Doug Cutting wrote:
> Doug Cutting wrote:
> > The calls would look like:
> >
> > new Field("name", "value", Stored.YES, Indexed.NO, Tokenized.YES);
> >
.
> Actually, while we're at it, Indexed and Tokenized are confounded. A
> single entry would be better, something l
Doug Cutting wrote:
The calls would look like:
new Field("name", "value", Stored.YES, Indexed.NO, Tokenized.YES);
Stored could be implemented as the nested class:
public final class Stored {
private Stored() {}
public static final Stored YES = new Stored();
public static final Stored NO = new
Kevin A. Burton wrote:
So I added a few constants to my class:
new Field( "name", "value", NOT_STORED, INDEXED, NOT_TOKENIZED );
which IMO is a lot easier to maintain.
Why not add these constants to Field.java:
public static final boolean STORED = true;
public static final boolean NOT_STORED
I've been working with the Field class doing index conversions between
an old index format to my new external content store proposal (thus the
email about the 14M convert).
Anyway... I find the whole Field.Keyword, Field.Text thing confusing.
The main problem is that the constructor to Field j
