[
https://issues.apache.org/jira/browse/SOLR-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205114#comment-13205114
]
Hoss Man commented on SOLR-2802:
--------------------------------
bq. In my opinion, I think if a user asks for min or max or some other
computation, and this is not possible, it should return an error? otherwise why
did they configure this in their chain?
Agreed, i'm not sure what usecase i had in mind when i wrote min/max to "pass
through" in this situation, but failing hard is definitely better -- at least
by default. If someone comes up with a reason not to fail, we can always add
an option later.
I've committed this change in r1242625.
bq. I think min/max should not extend this type-unsafe Subset base, as they
should not return a subset anyway, but a singleton, and the input must be
comparable...
If you'd like to take a stab at refactoring by all means be me guest. It's
true, these instances don't need to return a subset, but even if we change them
to not subclass that particular base class, I don't see any simple way to
rewrite them such that they only accept a Collection<Comparable>.
UpdateProcessors deal with SolrInputDocuments & SolrInputFields that are just
bags of objects; the schema hasn't been consulted yet, so we don't have any
hard type information about the types of these Objects (and even if we could we
wouldn't want to consult the schema yet, because some of these "fields" might
be for input purposes only -- some UpdateProcessor down the pipe might be
copying/moving them to different fields).
So if you want these Min/Max processors to have APIs that strictly enforce
Collection<Comparable<T>>, then some code somewhere needs to check that and
cast appropriately -- at the moment, they delegate that responsibility to
Collections.min and Collections.max, because that class does that check anyway
as it dos it's computation.
Personally i think the current impl is better anyway because in the common case
of clients sending "clean data" we don't waste cycles checking the type of
every Object sent before asking Collections.class to find the min/max and doing
the check again anyway. if an exceptional case happens, we catch/log/wrap the
exception.
> Toolkit of UpdateProcessors for modifying document values
> ---------------------------------------------------------
>
> Key: SOLR-2802
> URL: https://issues.apache.org/jira/browse/SOLR-2802
> Project: Solr
> Issue Type: New Feature
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-2802_update_processor_toolkit.patch,
> SOLR-2802_update_processor_toolkit.patch,
> SOLR-2802_update_processor_toolkit.patch,
> SOLR-2802_update_processor_toolkit.patch,
> SOLR-2802_update_processor_toolkit.patch
>
>
> Frequently users ask about questions about things where the answer is "you
> could do it with an UpdateProcessor" but the number of our of hte box
> UpdateProcessors is generally lacking and there aren't even very good base
> classes for the common case of manipulating field values when adding documents
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
