Hoss,
The new FieldValueSubsetUpdateProcessorFactory classes look phenomenal. I
haven't looked yet, but what are the chances these will be back-ported to
3.6 (or how hard would it be to backport them?)... I'll have to check out
the source in more detail.
If stuck on 3.6, what would be the best way to deal with this situation?
It's currently looking like it will have to be a custom update handler, but
I'd hate to have to go down this route if there are more future-proof
options.
Thanks again,
Aaron
On Tue, Jun 5, 2012 at 6:53 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote:
>
> : The real issue here is that the docs are created externally, and the
> : producer won't (yet) guarantee that fields that should appear once will
> : actually appear once. Because of this, I don't want to declare the field
> as
> : multiValued="false" as I don't want to cause indexing errors. It would be
> : great for me (and apparently many others after searching) if there were
> an
> : option as simple as forceSingleValued="true" - where some deterministic
> : behavior such as "use first field encountered, ignore all others", would
> : occur.
>
> This will be trivial in Solr 4.0, using one of the new
> "FieldValueSubsetUpdateProcessorFactory" classes that are now available --
> just pick your rule...
>
>
> https://builds.apache.org/view/G-L/view/Lucene/job/Solr-trunk/javadoc/org/apache/solr/update/processor/FieldValueSubsetUpdateProcessorFactory.html
> Direct Known Subclasses:
> FirstFieldValueUpdateProcessorFactory,
> LastFieldValueUpdateProcessorFactory,
> MaxFieldValueUpdateProcessorFactory,
> MinFieldValueUpdateProcessorFactory
>
> -Hoss
>
