You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by "Kevin A. Burton" <bu...@newsmonster.org> on 2004/07/11 11:04:38 UTC
Field.java -> STORED, NOT_STORED, etc...
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 just takes booleans
and if you forget the ordering of the booleans its very confusing.
new Field( "name", "value", true, false, true );
So looking at that you have NO idea what its doing without fetching javadoc.
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 = false;
public static final boolean INDEXED = true;
public static final boolean NOT_INDEXED = false;
public static final boolean TOKENIZED = true;
public static final boolean NOT_TOKENIZED = false;
Of course you still have to remember the order but this becomes a lot
easier to maintain.
Kevin
--
Please reply using PGP.
http://peerfear.org/pubkey.asc
NewsMonster - http://www.newsmonster.org/
Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Field.java -> STORED, NOT_STORED, etc...
Posted by Tatu Saloranta <ta...@hypermall.net>.
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 like:
...
> then calls would look like just:
>
> new Field("name", "value", Store.YES, Index.TOKENIZED);
...
> and adding a boolean clause would look like:
>
> booleanQuery.add(new TermQuery(...), Occur.MUST);
>
> Then we can deprecate the old methods.
>
> Comments?
I was about to suggest this, instead of int/boolean constants, since it is a
"recommended good practice", and allows better type safety (until JDK 1.5's
real enums at least). I would prefer this over un-typesafe consts; although
even just defining and using simple consts in itself would be an improvement
over existing situation.
Another possibility (or maybe complementary approach) would be to just
completely do away with constructor access; make the constructors private or
protected, and only allow factory methods to be used externally. This would
have the benefit of even better readability: minimum number of arguments
(method name would replace one or two args) and full type checking. Plus it'd
be easier to modify implementations should that become necessary. Factory
methods are especially useful for classes like Field, that are not designed
to be sub-classed.
-+ Tatu +-
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Field.java -> STORED, NOT_STORED, etc...
Posted by Doug Cutting <cu...@apache.org>.
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 Stored();
> }
Actually, while we're at it, Indexed and Tokenized are confounded. A
single entry would be better, something like:
public final class Index {
private Index() {}
public static final Index NO = new Index();
public static final Index TOKENIZED = new Index();
public static final Index UN_TOKENIZED = new Index();
}
then calls would look like just:
new Field("name", "value", Store.YES, Index.TOKENIZED);
BTW, I think Stored would be better named Store too.
BooleanQuery's required and prohibited flags could get the same
treatment, with the addition of a nested class like:
public final class Occur {
private Occur() {}
public static final Occur MUST_NOT = new Occur();
public static final Occur SHOULD = new Occur();
public static final Occur MUST = new Occur();
}
and adding a boolean clause would look like:
booleanQuery.add(new TermQuery(...), Occur.MUST);
Then we can deprecate the old methods.
Comments?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Field.java -> STORED, NOT_STORED, etc...
Posted by "Kevin A. Burton" <bu...@newsmonster.org>.
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 the nested class:
>
> public final class Stored {
> private Stored() {}
> public static final Stored YES = new Stored();
> public static final Stored NO = new Stored();
> }
+1... I'm not in love with this pattern but since Java < 1.4 doesnt'
support enum its better than nothing.
I also didn't want to submit a recommendation that would break APIs. I
assume the old API would be deprecated?
Kevin
--
Please reply using PGP.
http://peerfear.org/pubkey.asc
NewsMonster - http://www.newsmonster.org/
Kevin A. Burton, Location - San Francisco, CA, Cell - 415.595.9965
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
IRC - freenode.net #infoanarchy | #p2p-hackers | #newsmonster
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Field.java -> STORED, NOT_STORED, etc...
Posted by Doug Cutting <cu...@apache.org>.
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 = false;
>
> public static final boolean INDEXED = true;
> public static final boolean NOT_INDEXED = false;
>
> public static final boolean TOKENIZED = true;
> public static final boolean NOT_TOKENIZED = false;
>
> Of course you still have to remember the order but this becomes a lot
> easier to maintain.
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 the nested class:
public final class Stored {
private Stored() {}
public static final Stored YES = new Stored();
public static final Stored NO = new Stored();
}
and the compiler would check the order of arguments.
How's that?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org