You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2008/04/15 19:35:04 UTC

[jira] Issue Comment Edited: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)

    [ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12498336#action_12498336 ] 

hossman edited comment on SOLR-247 at 4/15/08 10:34 AM:
---------------------------------------------------------

I have a really hard time imagining anything but the most trivial use cases for facet.field=* ... it doesn't really sime like a problem in need of a solution.

with somehting like {{fl=\*}}, we're only talking about stored fields ... storing a field makes no sense unless you plan on returning it in the field list some of the time, so {{fl=\*}} makes sense as a "return all of hte fields that are possible to return" option.

There are *lots* of reasons why a field might be indexed though, so faceting on every indexed field doesn't seem like it would ever make sense.

in my opinion a "best practice" is not to use fl=* unless you are debugging anyway, otherwise you find yourself getting slammed with large amounts of data you don't want as the index evolves over time ... something like facet.field=* would be worse because it's not just the amount of data getting returned that would increase, but the amount of computation (and time and poor cache performance) that would spike as well.

if we do this, i would think it only makes sense to generalize the use of "*" in both fl and facet.field into a true glob style syntax, so we can at least encourage people who want this type of syntax to use a naming convention to help limit how much they hurt themselves.

(i have no problem giving people enough rope to hang themselves, but we shouldn't tie a noose in the rope before we give it to them)

 

      was (Author: hossman):
    I have a really hard time imagining anything but the most trivial use cases for facet.field=* ... it doesn't really sime like a problem in need of a solution.

with somehting like fl=*, we're only talking about stored fields ... storing a field makes no sense unless you plan on returning it in the field list some of the time, so fl=* makes sense as a "return all of hte fields that are possible to return" option.

There are *lots* of reasons why a field might be indexed though, so faceting on every indexed field doesn't seem like it would ever make sense.

in my opinion a "best practice" is not to use fl=* unless you are debugging anyway, otherwise you find yourself getting slammed with large amounts of data you don't want as the index evolves over time ... something like facet.field=* would be worse because it's not just the amount of data getting returned that would increase, but the amount of computation (and time and poor cache performance) that would spike as well.

if we do this, i would think it only makes sense to generalize the use of "*" in both fl and facet.field into a true glob style syntax, so we can at least encourage people who want this type of syntax to use a naming convention to help limit how much they hurt themselves.

(i have no problem giving people enough rope to hang themselves, but we shouldn't tie a noose in the rope before we give it to them)

 
  
> Allow facet.field=* to facet on all fields (without knowing what they are)
> --------------------------------------------------------------------------
>
>                 Key: SOLR-247
>                 URL: https://issues.apache.org/jira/browse/SOLR-247
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Ryan McKinley
>            Priority: Minor
>         Attachments: SOLR-247-FacetAllFields.patch
>
>
> I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok.
> This came out of trying to use faceting for the LukeRequestHandler top term collecting.
> http://www.nabble.com/Luke-request-handler-issue-tf3762155.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.