lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Friedman, Eric" <>
Subject RE: Bug? QueryParser may not correctly interpret RangeQuery text
Date Wed, 05 Jun 2002 16:00:13 GMT

I can confirm your suspicion about the poor performance of object
serialization and urge you to look elsewhere for a solution to this problem.


> -----Original Message-----
> From: Doug Cutting []
> Sent: Wednesday, June 05, 2002 8:34 AM
> To: Lucene Developers List
> Subject: Re: Bug? QueryParser may not correctly interpret RangeQuery
> text
> Brian Goetz wrote:
> > I still want to see Date and Number fields supported as 
> basic types in
> > the Field class, rather than "use a String in this magic 
> date format".
> The first part of this is easy: just add new Field 
> "constuctor" methods 
> that take Date and number parameters, e.g.:
>    Field.Keyword(String name, Date value);
>    Field.Keyword(String name, int value);
> (By the way, the reason I capitalized these static methods originally 
> was because I thought of them as constructors, which are capitalized, 
> but in retrospect it was probably a bad idea.  It was 1997 
> and this was 
> my first Java program...)
> The question is, what happens next?  The simple approach would be to 
> convert these values into strings that sort lexicographically 
> the same 
> as the dates and numbers, as is done by DateField.  But how 
> then do you 
> get the Date and number values back?
> The easy approach would be to add Document methods that returned the 
> value of a field as a Date or number, e.g.:
>    Date Document.getDate(String name);
>    int Document.getInt(String name);
> The downside of this approach is that typing is weak.  To fix 
> that would 
> require a revamp of the way that Lucene stores fields.  In 
> the general 
> case, we might want to move to using object serialization for field 
> values, however I suspect this would be much slower than the existing 
> implementation, and document de-serialization is already a 
> performance 
> bottleneck.
> A serialization-based approach might replace the Keyword method with:
>    Field.Keyword(String name, Object value);
> and the Document.get method with:
>    Object Document.get(String name);
> Are you okay with the easy approach?  Does someone want to 
> explore using 
> serialization for field values?
> Doug
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <>

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

View raw message