lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Shouldn't IndexWriter.commit(Map) accept Properties instead?
Date Mon, 22 Jun 2009 19:49:45 GMT
You could also serialize arbitrary objects into the index (Map<String,?>).
Not that this may not be good idea because of different class variants and
the known Java serialization problems, but it should principally work. And
Strings can also be serialized in the same way and are always
backwards-compatible (as far as you try to open the index with Lucene... --
I think this is the interesting point)

I have an index, where I have serialized objects in a stored binary field
(Object -> ObjectOutputStream(ByteArrayOutputStream)) -> binary field).
Works good.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
> Sent: Monday, June 22, 2009 9:43 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Shouldn't IndexWriter.commit(Map) accept Properties instead?
> 
> : 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)
> 
> 
> 
> -Hoss
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org



---------------------------------------------------------------------
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