lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: Bug? QueryParser may not correctly interpret RangeQuery text
Date Wed, 05 Jun 2002 15:33:38 GMT
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 

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?


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

View raw message