This project is read-only.

Field Serialization

Nov 7, 2007 at 7:22 PM

Cool Project. I'd love to contribute. Where do I sign up?

I think it's limiting that all class properties must be strings if they are to be indexed. Although lucene can only index strings, queries will be more powerful if they support non-string types too and document objects may better map to the programmers class hierarchy.

Indexing types anything other than strings is always weird. Decimals are usually multiplied out, numbers are range-bounded, zero padded and DateTimes are ISO formatted with fixed resolution...the list goes on depending on how you want a query and sort a field.

It would be nice if the following property types were supported:
  • int, int16, etc..
  • Decimal, float, double
  • DateTime
  • List<T> for supported types would be great for overloading fields. I'm not saying is easy or performant, but it'd be pretty cool.

To help stringification of these non-string fields, this project could supply a list of helper serializers, which could be declared in the FieldAttribute.

DateUtils offers a set of useful methods for formatting DateTimes at different resolutions, but feels alot like Java. LInq to Lucene could wrap that toolset or offer it's own declarative set of Date Formatters.

Common formats include
  • General Numbers
  • Prices
  • Lats/Longs
  • Seperated strings for DDrive/Folder1/Folder2
  • and many more...


Nov 7, 2007 at 8:52 PM
Edited Nov 7, 2007 at 8:55 PM
You're absolutely right, and the plan is to support more than just strings, and I plan to do that using TypeConverters. As long as the type or property supports a type-converter that takes a string we'll apply the type conversion.

For built-in types like those listed (int, decimal, datetime) we'll use their parse methods for type conversion.

Type-Conversion support will be added in one of the sooner releases.

Thanks for the interest and feedback. Send me an e-mail directly if you'd like to be a part of the project.
Nov 8, 2007 at 4:50 AM
Using TypeConverters is a great idea. I've never used TypeConverters before so that'll be interesting.

"For built-in types like those listed (int, decimal, datetime) we'll use their parse methods for type conversion. "

I think we'll need custom (de)serializers for those built in types rather than using the built in parse methods - depending how common decimal place shifting is.
Or did you mean use the parse method of TypeConverters?