Solr
  1. Solr
  2. SOLR-2519

Improve the defaults for the "text" field type in default schema.xml

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.3, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      Spinoff from: http://lucene.markmail.org/thread/ww6mhfi3rfpngmc5

      The text fieldType in schema.xml is unusable for non-whitespace
      languages, because it has the dangerous auto-phrase feature (of
      Lucene's QP – see LUCENE-2458) enabled.

      Lucene leaves this off by default, as does ElasticSearch
      (http://http://www.elasticsearch.org/).

      Furthermore, the "text" fieldType uses WhitespaceTokenizer when
      StandardTokenizer is a better cross-language default.

      Until we have language specific field types, I think we should fix
      the "text" fieldType to work well for all languages, by:

      • Switching from WhitespaceTokenizer to StandardTokenizer
      • Turning off auto-phrase
      1. SOLR-2519.patch
        39 kB
        Michael McCandless
      2. SOLR-2519.patch
        40 kB
        Michael McCandless
      3. SOLR-2519.patch
        26 kB
        Michael McCandless
      4. SOLR-2519.patch
        7 kB
        Michael McCandless

        Activity

        Hide
        Michael McCandless added a comment -

        Patch.

        I created a simple Chinese test, which fails w/ the defaults today and passes w/ the patch.

        Show
        Michael McCandless added a comment - Patch. I created a simple Chinese test, which fails w/ the defaults today and passes w/ the patch.
        Hide
        Michael McCandless added a comment -

        I think the attached patch is a good starting point. It fixes the
        generic "text" fieldType to have good all around defaults for all
        languages, so that non-whitespace languages work fine.

        Then, I think we should iteratively add in custom languages over time
        (as separate issues). We can eg add text_en_autophrase, text_en,
        text_zh, etc. We should at least do first sweep of nice analyzers
        module and add fieldTypes for them.

        This way we will eventually get to the ideal future when we have
        text_XX coverage for many languages.

        Show
        Michael McCandless added a comment - I think the attached patch is a good starting point. It fixes the generic "text" fieldType to have good all around defaults for all languages, so that non-whitespace languages work fine. Then, I think we should iteratively add in custom languages over time (as separate issues). We can eg add text_en_autophrase, text_en, text_zh, etc. We should at least do first sweep of nice analyzers module and add fieldTypes for them. This way we will eventually get to the ideal future when we have text_XX coverage for many languages.
        Hide
        Yonik Seeley added a comment -

        I think maybe there's a misconception that the fieldType named "text" was meant to be generic for all languages. As I said in the thread, if I had to do it over again, I would have named it "text_en" because that's what it's purpose was. But at this point, it seems like the best way forward is to leave "text" as an english fieldType and simply add other fieldTypes that can support other languages.

        Some downsides I see to this patch (i.e. trying to make the 'text' fieldType generic):

        • The current WordDelimiterFilter options the fieldType feel like a trap for non-whitespace-delimited languages. WDF is configured to index catenations as well as splits... so all of the tokens (words?) that are split out are also catenated together and indexed (which seems like it could lead to some truly huge tokens erroneously being indexed.)
        • You left the english stemmer on the "text" fieldType... but if it's supposed to be generic, couldn't this be bad for some other western languages where it could cause stemming collisions of words not related to each other?

        Taking into account all the existing users (and all the existing documentation, examples, tutorial, etc), I favor a more conservative approach of adding new fieldTypes rather than radically changing the behavior of existing ones.

        Random question: what are the implications of changing from WhitespaceTokenizer to StandardTokenizer, esp w.r.t. WDF?

        Show
        Yonik Seeley added a comment - I think maybe there's a misconception that the fieldType named "text" was meant to be generic for all languages. As I said in the thread, if I had to do it over again, I would have named it "text_en" because that's what it's purpose was. But at this point, it seems like the best way forward is to leave "text" as an english fieldType and simply add other fieldTypes that can support other languages. Some downsides I see to this patch (i.e. trying to make the 'text' fieldType generic): The current WordDelimiterFilter options the fieldType feel like a trap for non-whitespace-delimited languages. WDF is configured to index catenations as well as splits... so all of the tokens (words?) that are split out are also catenated together and indexed (which seems like it could lead to some truly huge tokens erroneously being indexed.) You left the english stemmer on the "text" fieldType... but if it's supposed to be generic, couldn't this be bad for some other western languages where it could cause stemming collisions of words not related to each other? Taking into account all the existing users (and all the existing documentation, examples, tutorial, etc), I favor a more conservative approach of adding new fieldTypes rather than radically changing the behavior of existing ones. Random question: what are the implications of changing from WhitespaceTokenizer to StandardTokenizer, esp w.r.t. WDF?
        Hide
        Michael McCandless added a comment -

        I think maybe there's a misconception that the fieldType named "text" was meant to be generic for all languages.

        Regardless of what the original intention was, "text" today has become
        the generic text fieldType new users use on starting with Solr. I
        mean, it has the perfect name for that

        As I said in the thread, if I had to do it over again, I would have named it "text_en" because that's what it's purpose was.

        Hindsight is 20/20... but, we can still fix this today. We shouldn't
        lock ourselves into poor defaults.

        Especially, as things improve and we get better analyzers, etc., we
        should be free to improve the defaults in schema.xml to take advantage
        of these improvements.

        But at this point, it seems like the best way forward is to leave "text" as an english fieldType and simply add other fieldTypes that can support other languages.

        I think this is a dangerous approach – the name (ie, missing _en if
        in fact it has such English-specific configuration) is misleading and
        traps new users.

        Ideally, in the future, we wouldn't even have a "text" fieldType, only
        text_XX per-language examples and then maybe something like
        text_general, which you use if you cannot find your language.

        Some downsides I see to this patch (i.e. trying to make the 'text' fieldType generic):

        The current WordDelimiterFilter options the fieldType feel like a trap for non-whitespace-delimited languages. WDF is configured to index catenations as well as splits... so all of the tokens (words?) that are split out are also catenated together and indexed (which seems like it could lead to some truly huge tokens erroneously being indexed.)

        Ahh good point. I think we should remove WDF altogether from the
        generic "text" fieldType.

        You left the english stemmer on the "text" fieldType... but if it's supposed to be generic, couldn't this be bad for some other western languages where it could cause stemming collisions of words not related to each other?

        +1, we should remove the stemming too from "text".

        Taking into account all the existing users (and all the existing documentation, examples, tutorial, etc), I favor a more conservative approach of adding new fieldTypes rather than radically changing the behavior of existing ones.

        Can you point to specific examples (docs, examples, tutorial)? I'd
        like to understand how much work it is to fix these...

        My feeling is we should simply do the work here (I'll sign up to it)
        and fix any places that actually rely on the specifics of "text"
        fieldType, eg autophrase.

        We shouldn't avoid fixing things well because it's gonna be more work
        today, especially if someone (me) is signing up to do it.

        Also: existing users would be unaffected by this? They've already
        copied over / edited their own schema.xml? This is mainly about new
        users?

        Show
        Michael McCandless added a comment - I think maybe there's a misconception that the fieldType named "text" was meant to be generic for all languages. Regardless of what the original intention was, "text" today has become the generic text fieldType new users use on starting with Solr. I mean, it has the perfect name for that As I said in the thread, if I had to do it over again, I would have named it "text_en" because that's what it's purpose was. Hindsight is 20/20... but, we can still fix this today. We shouldn't lock ourselves into poor defaults. Especially, as things improve and we get better analyzers, etc., we should be free to improve the defaults in schema.xml to take advantage of these improvements. But at this point, it seems like the best way forward is to leave "text" as an english fieldType and simply add other fieldTypes that can support other languages. I think this is a dangerous approach – the name (ie, missing _en if in fact it has such English-specific configuration) is misleading and traps new users. Ideally, in the future, we wouldn't even have a "text" fieldType, only text_XX per-language examples and then maybe something like text_general, which you use if you cannot find your language. Some downsides I see to this patch (i.e. trying to make the 'text' fieldType generic): The current WordDelimiterFilter options the fieldType feel like a trap for non-whitespace-delimited languages. WDF is configured to index catenations as well as splits... so all of the tokens (words?) that are split out are also catenated together and indexed (which seems like it could lead to some truly huge tokens erroneously being indexed.) Ahh good point. I think we should remove WDF altogether from the generic "text" fieldType. You left the english stemmer on the "text" fieldType... but if it's supposed to be generic, couldn't this be bad for some other western languages where it could cause stemming collisions of words not related to each other? +1, we should remove the stemming too from "text". Taking into account all the existing users (and all the existing documentation, examples, tutorial, etc), I favor a more conservative approach of adding new fieldTypes rather than radically changing the behavior of existing ones. Can you point to specific examples (docs, examples, tutorial)? I'd like to understand how much work it is to fix these... My feeling is we should simply do the work here (I'll sign up to it) and fix any places that actually rely on the specifics of "text" fieldType, eg autophrase. We shouldn't avoid fixing things well because it's gonna be more work today, especially if someone (me) is signing up to do it. Also: existing users would be unaffected by this? They've already copied over / edited their own schema.xml? This is mainly about new users?
        Hide
        Michael McCandless added a comment -

        It's also spooky that "text" fieldType has different index
        time vs query time analyzers? Ie, WDF is configured differently.

        Show
        Michael McCandless added a comment - It's also spooky that "text" fieldType has different index time vs query time analyzers? Ie, WDF is configured differently.
        Hide
        Hoss Man added a comment -

        I feel like we are convoluting two issues here: the "default" behavior of TextField, and the example configs.

        i don't have any strong opinions about changing the default behavior of TextField when autoGeneratePhraseQueries is not specified in the <fieldType/> but if we do make such a change, it should be contingent on the schema version property (which we should bump) so that people who upgrade will get consistent behavior with their existing configs (TextField.init already has an example of this for when we changed the default of omitNorms)

        as far as the example configs: i agree with yonik, that changing "text" at this point might be confusing ... i think the best way to iterate moving forward would probably be:

        • rename <fieldType name="text"/> and <field name="text"/> to something that makes their purpose more clear (text_en, or text_western, or text_european, or some other more general descriptive word for the types of languages were it makes sense) and switch all existing <field/> declarations that currently use use field type "text" to use this new name.
        • add a new <fieldType name="text_general"/> which is designed (and documented to be a general purpose field type when the language is unknown (it may make sense to fix/repurpose the existing <fieldType name="textgen"/> for this, since it already suggests that's what it's for)
        • Audit all <field/> declarations that use "text_en" (or whatever name was chosen above) and the existing sample data for those fields to see if it makes more sense to change them to "text_general". also change any where based on usage it shouldn't matter.

        The end result being that we have no <fieldType/> named "text" in the example configs, so people won't get it confused with previous versions, and we'll have a new <fieldType/> that works as well as possible with all langauges which we use as much as possible with the example data.

        Show
        Hoss Man added a comment - I feel like we are convoluting two issues here: the "default" behavior of TextField, and the example configs. i don't have any strong opinions about changing the default behavior of TextField when autoGeneratePhraseQueries is not specified in the <fieldType/> but if we do make such a change, it should be contingent on the schema version property (which we should bump) so that people who upgrade will get consistent behavior with their existing configs (TextField.init already has an example of this for when we changed the default of omitNorms ) as far as the example configs: i agree with yonik, that changing "text" at this point might be confusing ... i think the best way to iterate moving forward would probably be: rename <fieldType name="text"/> and <field name="text"/> to something that makes their purpose more clear (text_en, or text_western, or text_european, or some other more general descriptive word for the types of languages were it makes sense) and switch all existing <field/> declarations that currently use use field type "text" to use this new name. add a new <fieldType name="text_general"/> which is designed (and documented to be a general purpose field type when the language is unknown (it may make sense to fix/repurpose the existing <fieldType name="textgen"/> for this, since it already suggests that's what it's for) Audit all <field/> declarations that use "text_en" (or whatever name was chosen above) and the existing sample data for those fields to see if it makes more sense to change them to "text_general". also change any where based on usage it shouldn't matter. The end result being that we have no <fieldType/> named "text" in the example configs, so people won't get it confused with previous versions, and we'll have a new <fieldType/> that works as well as possible with all langauges which we use as much as possible with the example data.
        Hide
        Hoss Man added a comment -

        Also: existing users would be unaffected by this? They've already copied over / edited their own schema.xml? This is mainly about new users?

        The trap we've seen with this type of thing in the past (ie: the numeric fields) is that people who tend to use the example configs w/o changing them much refer to the example field types by name when talking about them on the mailing list, not considering that those names can have differnet meanings depending on version.

        if we make radical changes to a <fieldType/> but leave the name alone, it could confuse a lot of people, ie: "i tried using the 'text' field but it didn't work"; "which version of solr are you using?"; "Solr 4.1"; "that should work, what exactly does your schema look like"; "..."; "that's the schema from 3.6"; "yeah, i started with 3.6 nad then upgraded to 4.1 later", etc...

        Bottom line: it's less confusing to remove <fieldType/> and add new ones with new names then to make radical changes to existing ones.

        Show
        Hoss Man added a comment - Also: existing users would be unaffected by this? They've already copied over / edited their own schema.xml? This is mainly about new users? The trap we've seen with this type of thing in the past (ie: the numeric fields) is that people who tend to use the example configs w/o changing them much refer to the example field types by name when talking about them on the mailing list, not considering that those names can have differnet meanings depending on version. if we make radical changes to a <fieldType/> but leave the name alone, it could confuse a lot of people, ie: "i tried using the 'text' field but it didn't work"; "which version of solr are you using?"; "Solr 4.1"; "that should work, what exactly does your schema look like"; "..."; "that's the schema from 3.6"; "yeah, i started with 3.6 nad then upgraded to 4.1 later", etc... Bottom line: it's less confusing to remove <fieldType/> and add new ones with new names then to make radical changes to existing ones.
        Hide
        Michael McCandless added a comment -

        Bottom line: it's less confusing to remove <fieldType/> and add new ones with new names then to make radical changes to existing ones.

        Ahh, this makes great sense!

        I really like your proposal Hoss, and that's a great point about emails to the mailing lists.

        So we'd have no more text fieldType. Just text_en (what text now is) and text_general (basically just StandardAnalyzer, but maybe move/absorb "textgen" over).

        Over time we can add in more language specific text_XX fieldTypes...

        Show
        Michael McCandless added a comment - Bottom line: it's less confusing to remove <fieldType/> and add new ones with new names then to make radical changes to existing ones. Ahh, this makes great sense! I really like your proposal Hoss, and that's a great point about emails to the mailing lists. So we'd have no more text fieldType. Just text_en (what text now is) and text_general (basically just StandardAnalyzer, but maybe move/absorb "textgen" over). Over time we can add in more language specific text_XX fieldTypes...
        Hide
        Robert Muir added a comment -

        As someone frustrated by this (but who would ultimately like to move past it and try to help with solr's intl), I just wanted to say +1 to Hoss Man's proposal.

        My only suggestion on what he said is that I would greatly prefer text_en over text_western or whatever for these reasons:
        1. the stemming and stopwords and crap here are english.
        2. for other western languages, even if you swap these out to be say, french or italian (which is the seemingly obvious way to cut over), the whole WDF+autophrase is still a huge trap (see http://www.hathitrust.org/blogs/large-scale-search/tuning-search-performance for an example). in this case use of ElisionFilter can be taken to avoid it.

        Show
        Robert Muir added a comment - As someone frustrated by this (but who would ultimately like to move past it and try to help with solr's intl), I just wanted to say +1 to Hoss Man's proposal. My only suggestion on what he said is that I would greatly prefer text_en over text_western or whatever for these reasons: 1. the stemming and stopwords and crap here are english. 2. for other western languages, even if you swap these out to be say, french or italian (which is the seemingly obvious way to cut over), the whole WDF+autophrase is still a huge trap (see http://www.hathitrust.org/blogs/large-scale-search/tuning-search-performance for an example). in this case use of ElisionFilter can be taken to avoid it.
        Hide
        Jan Høydahl added a comment -

        Largely agree with @Hoss' suggestion. But I think it would be wise to emphasize that the example schema is just that - an example - encouraging people to create new fieldTypes instead of editing the example ones. It's not a problem for "int", "date" etc, but for text I always encourage our customers and students to stay away from the FieldTypes in the example and make their own versions instead.

        One way to further encourage this best practice is naming all text FieldTypes clearly as examples, e.g.

        <fieldType name="text_example_en" ..>
        <fieldType name="text_example_generic" ..>
        

        We must realize that a lot of non-american users out there are already customizing their schemas with the naming pattern "text_<lang>", which means you'll find "text_en", "text_it", "text_no" in a lot of installations. Therefore it would be un-wise to introduce new FieldTypes wich crashes with those names out of the box in version 3.2, thus include _example in the type name.

        When upgrading, I always leave all the example field types intact, and add my custom ones separately, clearly marked by comments for easy copy/paste. I believe this to be a fairly common practice, and wanted as well, which would give no clashes for the above example.

        With this example naming practice, we can be pretty sure that if people talk about the fieldType "text_example_en" on the lists, they mean the default example type, but if they talk about "text_en", it's something they've customized themselves (if so by simply renaming the example). It'll be more mental resitance for people to start modifying something with "_example" in it wihout also changing the name.

        Show
        Jan Høydahl added a comment - Largely agree with @Hoss' suggestion. But I think it would be wise to emphasize that the example schema is just that - an example - encouraging people to create new fieldTypes instead of editing the example ones. It's not a problem for "int", "date" etc, but for text I always encourage our customers and students to stay away from the FieldTypes in the example and make their own versions instead. One way to further encourage this best practice is naming all text FieldTypes clearly as examples, e.g. <fieldType name= "text_example_en" ..> <fieldType name= "text_example_generic" ..> We must realize that a lot of non-american users out there are already customizing their schemas with the naming pattern "text_<lang>", which means you'll find "text_en", "text_it", "text_no" in a lot of installations. Therefore it would be un-wise to introduce new FieldTypes wich crashes with those names out of the box in version 3.2, thus include _example in the type name. When upgrading, I always leave all the example field types intact, and add my custom ones separately, clearly marked by comments for easy copy/paste. I believe this to be a fairly common practice, and wanted as well, which would give no clashes for the above example. With this example naming practice, we can be pretty sure that if people talk about the fieldType "text_example_en" on the lists, they mean the default example type, but if they talk about "text_en", it's something they've customized themselves (if so by simply renaming the example). It'll be more mental resitance for people to start modifying something with "_example" in it wihout also changing the name.
        Hide
        Michael McCandless added a comment -

        +1 to naming these fields text_example_XXX. That's a great idea Jan. I'll do that in my next patch...

        Show
        Michael McCandless added a comment - +1 to naming these fields text_example_XXX. That's a great idea Jan. I'll do that in my next patch...
        Hide
        Michael McCandless added a comment -

        New patch, incorporating the great ideas above:

        • Renamed all textX fields -> text_example_X
        • I bumped schema version to 1.4; autophrase is off for TextField if
          schema version > 1.3; else, on.
        • Renamed existing "text" field type as "text_example_en_splitting"
        • Made a new "text_example_en" field type, just like
          text_example_en_splitting but uses standard tokenizer (plug
          english posessive stripping), turns off WDF and autophrase.
        • Made a text_example_general field type (absorbing textgen into
          it): standard tokenizer, stopwords, downcase.
        • Renamed textTight field type to text_example_en_spliting_tight
        • Changed all text* fields to use text_example_general
        • Renamed stopwords.text -> stopwords_en.txt (referenced only from
          the text_en* field types); put a new empty stopwords.txt file in
          its place.
        Show
        Michael McCandless added a comment - New patch, incorporating the great ideas above: Renamed all textX fields -> text_example_X I bumped schema version to 1.4; autophrase is off for TextField if schema version > 1.3; else, on. Renamed existing "text" field type as "text_example_en_splitting" Made a new "text_example_en" field type, just like text_example_en_splitting but uses standard tokenizer (plug english posessive stripping), turns off WDF and autophrase. Made a text_example_general field type (absorbing textgen into it): standard tokenizer, stopwords, downcase. Renamed textTight field type to text_example_en_spliting_tight Changed all text* fields to use text_example_general Renamed stopwords.text -> stopwords_en.txt (referenced only from the text_en* field types); put a new empty stopwords.txt file in its place.
        Hide
        Michael McCandless added a comment -

        New patch, fixes the tutorial (mainly the text analysis section, but also lots of little "collateral improvements").

        I think it's ready to commit!

        Show
        Michael McCandless added a comment - New patch, fixes the tutorial (mainly the text analysis section, but also lots of little "collateral improvements"). I think it's ready to commit!
        Hide
        Robert Muir added a comment -

        A few opinions:

        1. First of all, I am +1 to the patch. I think its an improvement overall, however I think it might be worthwhile to discuss the following issues below.

        2. I think we need to stop kidding ourselves about example/default and just recognize that 99.99999999999% of users just use the example as their default configuration. Guys, the example is the default, there is simply not argument, this is the reality! So I think we should present reasonable field type names such as text_en etc. Please don't waste any more of our time trying to convince users that the default is actually an example, its a default.

        3. The aggressive analysis is totally unnecessary and gives bad results, this is not 1985... Lets drop the porter stemmer and the stopwords list and replace them with less aggressive defaults such as s-stemmer and a commongrams configuration.

        4. I do not think the default query parser should be the lucene one, if we have a fancy one (edismax?) that happily handles user input without exceptions... why not just default to the best we have to offer?!

        Show
        Robert Muir added a comment - A few opinions: 1. First of all, I am +1 to the patch. I think its an improvement overall, however I think it might be worthwhile to discuss the following issues below. 2. I think we need to stop kidding ourselves about example/default and just recognize that 99.99999999999% of users just use the example as their default configuration. Guys, the example is the default, there is simply not argument, this is the reality! So I think we should present reasonable field type names such as text_en etc. Please don't waste any more of our time trying to convince users that the default is actually an example, its a default. 3. The aggressive analysis is totally unnecessary and gives bad results, this is not 1985... Lets drop the porter stemmer and the stopwords list and replace them with less aggressive defaults such as s-stemmer and a commongrams configuration. 4. I do not think the default query parser should be the lucene one, if we have a fancy one (edismax?) that happily handles user input without exceptions... why not just default to the best we have to offer?!
        Hide
        Michael McCandless added a comment -

        I think we need to stop kidding ourselves about example/default and just recognize that 99.99999999999% of users just use the example as their default configuration. Guys, the example is the default, there is simply not argument, this is the reality! So I think we should present reasonable field type names such as text_en etc. Please don't waste any more of our time trying to convince users that the default is actually an example, its a default.

        OK I agree. So I'll rename the fields back to text_XX (instead of text_example_XX).

        3. The aggressive analysis is totally unnecessary and gives bad results, this is not 1985... Lets drop the porter stemmer and the stopwords list and replace them with less aggressive defaults such as s-stemmer and a commongrams configuration.

        Sounds great! Can you post the analyzer XML for this....? Kinda out of my league at this point

        4. I do not think the default query parser should be the lucene one, if we have a fancy one (edismax?) that happily handles user input without exceptions... why not just default to the best we have to offer?!

        +1

        Robert maybe you can take the patch and iterate w/ these changes...?

        Show
        Michael McCandless added a comment - I think we need to stop kidding ourselves about example/default and just recognize that 99.99999999999% of users just use the example as their default configuration. Guys, the example is the default, there is simply not argument, this is the reality! So I think we should present reasonable field type names such as text_en etc. Please don't waste any more of our time trying to convince users that the default is actually an example, its a default. OK I agree. So I'll rename the fields back to text_XX (instead of text_example_XX). 3. The aggressive analysis is totally unnecessary and gives bad results, this is not 1985... Lets drop the porter stemmer and the stopwords list and replace them with less aggressive defaults such as s-stemmer and a commongrams configuration. Sounds great! Can you post the analyzer XML for this....? Kinda out of my league at this point 4. I do not think the default query parser should be the lucene one, if we have a fancy one (edismax?) that happily handles user input without exceptions... why not just default to the best we have to offer?! +1 Robert maybe you can take the patch and iterate w/ these changes...?
        Hide
        Michael McCandless added a comment -

        New patch attached. Only change vs last patch is to remove _example from the field types, so now we have text_general, text_en, etc.

        I think for the other fun improvements (less aggressive stemming, alternatives to stop word removal, better default query parser) we should open new issues? Progress not perfection...

        I'll commit this one shortly.

        Show
        Michael McCandless added a comment - New patch attached. Only change vs last patch is to remove _example from the field types, so now we have text_general, text_en, etc. I think for the other fun improvements (less aggressive stemming, alternatives to stop word removal, better default query parser) we should open new issues? Progress not perfection... I'll commit this one shortly.
        Hide
        Michael McCandless added a comment -

        Thanks everyone!

        Robert, can you open followon issues for your other ideas? I think they are important... we should put forth the best defaults Lucene/Solr has to offer here.

        Show
        Michael McCandless added a comment - Thanks everyone! Robert, can you open followon issues for your other ideas? I think they are important... we should put forth the best defaults Lucene/Solr has to offer here.
        Hide
        Robert Muir added a comment -

        Bulk close for 3.3

        Show
        Robert Muir added a comment - Bulk close for 3.3

          People

          • Assignee:
            Michael McCandless
            Reporter:
            Michael McCandless
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development