[
https://issues.apache.org/jira/browse/SOLR-16260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-16260:
----------------------------------
Labels: pull-request-available (was: )
> Handle JSR310 Date classes in JavaBinCodec
> ------------------------------------------
>
> Key: SOLR-16260
> URL: https://issues.apache.org/jira/browse/SOLR-16260
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 9.0, 8.11.1
> Reporter: Sebastian Gift
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> JavaBinCodec currently only supports java.util.Date as Date input and doesn't
> handle JSR310 classes like Instant or LocalDate. As a result adding a
> SolrInputDocument which contains a LocalDate will be serialized in SolrJ as
> java.time.LocalDate:2022-12-31 using the fallback logic in
> JavaBinCodec#writeVal. This value then gets parsed on the server and throws
> an exception if the field is defined as a date field in the schema.
> I've written a small PR on Github to support ZonedDateTime, LocalDate and
> Instant as variants of Date (all get stored in Javabin as epoch millis and
> converted to Date on deserializing). I've not added support for LocalDateTime
> since it lacks enough information to be converted to epoch millis, but maybe
> there should be some warning or error provided to show that it isn't
> supported by SolrJ (instead of the generic "Couldn't parse date because:
> Improperly formatted datetime:" Exception)
>
> Note: A user could provide the value either as String (e.g. using
> Instant#toString) or ObjectResolver, which gets parsed correctly, but
> compared to the handling of java.util.Date that's not very intuitive.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
