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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
