lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2802) Toolkit of UpdateProcessors for modifying document values
Date Fri, 10 Feb 2012 00:44:57 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message