[
https://issues.apache.org/jira/browse/SOLR-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13693316#comment-13693316
]
Steve Rowe commented on SOLR-4892:
----------------------------------
Thanks Hoss, thanks for the review, I'll work on your suggestions and put up a
patch later today.
About your questions:
bq. 7) Why no ParseIntFieldUpdateProcessor and ParseFloatFieldUpdateProcessor ?
Because I wasn't going to use them for the schemaless mode example config
(which is the driver here), I was keeping the issue lean, but I can add them.
bq. 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?
I didn't know about the commons-lang method, but I separated the locale
components for two reasons: 1) Java 7 has a new method
[Locale.forLanguageTag()|http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#forLanguageTag(java.lang.String)]
that does this, but for 4.X, we can't use it, since it's on Java 6; and 2)
there is a precedent for separately configured locale components in
BreakIteratorBoundaryScanner: HighlightParams.BS_LANGUAGE and .BS_COUNTRY
("hl.bs.language" and "hl.bs.country", respectively). I'm fine switching to
LocaleUtils.toLocale with a single "locale" configuration item, though; I agree
it would be simpler for users.
bq. 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?
Yes, I'll do that.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
