lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Shouldn't IndexWriter.commit(Map) accept Properties instead?
Date Mon, 22 Jun 2009 20:14:14 GMT
On Mon, Jun 22, 2009 at 3:43 PM, Chris
Hostetter<hossman_lucene@fucit.org> wrote:
> : The javadocs state clearly it must be Map<String,String>.  Plus, the
> : type checking is in fact enforced (you hit an exception if you violate
> : it), dynamically (like Python).
> :
> : And then I was thinking with 1.5 (3.0 -- huh, neat how it's exactly
> : 2X) we'd statically type it (change Map to Map<String,String>).
>
> the other option i've seen in similar situations is to document that
> Map<Object,Object> is allowed, but that the Object will be toString()ed
> and the resulting value is what will be used.
>
> In the common case of Strings, the functionality is the same without
> requiring any explicit casting or instanceof error checking.
>
> the added bonuses are:
>  1) people can pass other "simple" objects (Integers, Foats, Booleans)
> and 99% of the time get what they want.
>  2) people can pass wrapper objects that implement toString() in a non
> trivial way and have the string produced for them lazily when the time
> comes to use the String.  (ie: if my string value is expensive to produce,
> i can defer that cost until needed in case the commit fails for some other
> reason before my string is even used)

But then when you retrieve your metadata it's converted to String -> String.

Mike

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


Mime
View raw message