lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Date Wed, 01 Dec 2004 20:14:59 GMT

: > Having Document implement Map sounds reasonable to me though.  Any
: > reasons not to do this?
: Not really, except perhaps that a Lucene Document could theoretically
: have multiple identical keys... not something that anyone would want to

Assuming you want all changes to be backwards compatible, you pretty much
have to impliment Map.get(Object):Object usig Document.get(String):String
... otherwise you'll wind up really confusing the hell out of people.  But
If you really wanted to be mean to people, I guess you could use
Document.getField(String):Field or even
Document.getValues(String):String[] or Document.getFields(String):Fields[]
if you were feeling particularly mean.

The real question in my mind is not "how should we impliment 'get' given
that we allow multiple values?", a better question is "how should we
impliment 'put'?"

do you write...
       Object put(Object k, Object v) {
           return null;
       Object put(String k, String v) {
           return null;
       Object put(String k, String v) {
	   throw new UnsupportedOperationException("we're not that nice");

...i think it may be wiser to just let clinets wrap the Doc in their own
Map, using the rules that make sense to them -- becuase no ones ever going
to agree 100%.

If you think you know how to satisfy 90% of the users, i would still
suggest that instead of making Codument impliment Map, instead add
a "toMap()" functin that returns a wrapper with the rules that you think
make sense.  (and leave the Document API uncluttered of the Map functions
that people who don't care about Map don't need to see)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message