I like your suggestion. To keep the index working the same, I have just switched to dates and added the string "T23:59:59Z" and it seems to make the solr.DateField happy when this string is passed.
It will mean I will have to mess with it on the way back in - but it should be okay. To have solr-ruby do this to dates for me would be ideal. if field.class == Date field = field.to_s + "T23:59:59Z" end On Tue, Aug 12, 2008 at 5:11 AM, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > On Aug 11, 2008, at 3:03 PM, Ian Connor wrote: >> >> I originally used a Ruby Date class for my dates, but found when I set >> the type to solr.DateField in the solrconfig.xml, it returned a parse >> error. After that, I switched to Time and it worked fine. >> >> However, I now have some dates that are out of the Time range (e.g. >> 1865) so Date would work better here than time. >> >> What is the best strategy here: >> 1. Use Dates and treat it as a solr.String; >> 2. Customize the Date class to output a valid solr.DateField string; or >> 3. Treat it as a string in ruby and handle to/from Date in my model? > > I've thought about this some myself and I the proposal I have is to enhance > Solr's Ruby output to provide real DateTime objects rather than strings. > I've added this as a TODO here: > <https://issues.apache.org/jira/browse/SOLR-358>, but haven't made time to > do anything with it myself yet. > > As far as a specific recommendation for your use here - if you aren't > leveraging any date sorting or (range) querying capabilities then it would > be fine to treat it as a string within Solr. How you configure Solr's types > depend entirely on what you want to do with those fields from a query and > storage perspective. > > Erik > > -- Regards, Ian Connor
