[
https://issues.apache.org/jira/browse/SOLR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-4892:
-----------------------------
Attachment: SOLR-4892.patch
[[email protected]], this version of the patch includes fixes for all
your suggestions.
Details:
{quote}
1) AllValuesOrNoneFieldMutatingUpdateProcessor semantics
The "if (destVal == srcVal) ... do nothing" logic [...] give subclasses another
singleton marker object [...] they can return from mutateValue() to say "abort
processing this list i have encountered an object i do not want". If
mutateValue() returns the same object it was passed in, that should be
considered a successful mutation.
{quote}
Done.
{quote}
2) ParsingFieldUpdateProcessor overriding processAdd
[...] we don't need this class at all, classes like
ParseFooFieldUpdateProcessor could easily just handle the CharSequence check as
part of their basic logic...
{quote}
Done - I chose this route and got rid of ParsingFieldUpdateProcessor.
{quote}
3) either way we go with #2, that means we don't need the access modifieier
change on 'selector' in FieldMutatingUpdateProcessor.
{quote}
Fixed.
{quote}
double check the handling of field boosts in
AllValuesOrNoneFieldMutatingUpdateProcessor ... pretty sure it isn't being
preserved (see FieldValueMutatingUpdateProcessor for example)
{quote]
Fixed.
{quote}
5) The SortableFooField FieldType's should also be decorated with your new
interfaces.
{quote}
Done.
{quote}
6) Can we refactor the locale init param parsing into a helper utility class or
a common factory bsae class so it's not duplicated in both
ParseNumericFieldUpdateProcessorFactory and
ParseDateFieldUpdateProcessorFactory ?
8) would it be simpler for users to have a single "locale" init param that
accepted things like "ru" and "ru_RU" and "ru_RU_xxx" using
LocaleUtils.toLocale in commons-lang?
{quote}
I switched to using a single "locale" config item, using commons-lang
LocaleUtils.toLocale(). This is so small I didn't try to consolidate, I just
replicated in the two places.
{quote}
7) Why no ParseIntFieldUpdateProcessor and ParseFloatFieldUpdateProcessor ?
{quote}
Added.
{quote}
9) we should be able to make the ParseFooFieldUpdateProcessor inner classses
into static inner classes just by passing hte locale into the constructor and
right?
{quote}
I did this for the Date and Numeric processors, but the Boolean processor
factory has a couple of configured collections and a boolean, so I didn't
convert its processor to a static inner class.
> Add field update processors to parse/convert String-typed fields to Date,
> Number, and Boolean
> ---------------------------------------------------------------------------------------------
>
> Key: SOLR-4892
> URL: https://issues.apache.org/jira/browse/SOLR-4892
> Project: Solr
> Issue Type: New Feature
> Components: update
> Reporter: Steve Rowe
> Assignee: Steve Rowe
> Priority: Minor
> Fix For: 4.4
>
> Attachments: SOLR-4892.patch, SOLR-4892.patch
>
>
> Add {{FieldMutatingUpdateProcessorFactory}} subclasses
> {{ParseFooUpdateProcessorFactory}}, where {{Foo}} includes {{Date}},
> {{Double}}, {{Long}}, and {{Boolean}}.
> These factories will have a default selector that matches all fields that
> either don’t match any schema field, or are in the schema with the
> corresponding {{typeClass}}. They can optionally support a list of multiple
> format specifiers. If they see a value that is not a CharSequence, or can't
> parse the value using a configured format, they ignore it and leave it as is.
> For multi-valued fields, these processors will not convert any values unless
> all are first successfully parsed. Ordering the processors [Boolean, Long,
> Double, Date] will allow e.g. values [2, 5, 8.6] to be left alone by the
> Boolean and Long processors, but then converted by the Double processor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
