lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Tucker" <m...@jivesoftware.com>
Subject RE: Bug? QueryParser may not correctly interpret RangeQuery text
Date Wed, 05 Jun 2002 16:24:53 GMT
Hey All,

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

Shouldn't it be possible to short-circuit serialization for commonly
used types such as Date, Long, String, Integer, etc? I've seen many
projects do this to provide generalized support for any Serializable
object, but speed for common usage scenarios.

Regards,
Matt

> > -----Original Message-----
> > From: Doug Cutting [mailto:cutting@lucene.com]
> > 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:   
> <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:lucene-dev-help@jakarta.apache.org>
> 
> --
> To 
> unsubscribe, e-mail:   
> <mailto:lucene-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:lucene-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message