FAQ
Improve analyzer/version handling in Solr
-----------------------------------------

Key: SOLR-2259
URL: https://issues.apache.org/jira/browse/SOLR-2259
Project: Solr
Issue Type: Task
Reporter: Robert Muir
Fix For: 3.1, 4.0


We added Version for backwards compatibility support in Lucene.
We use this to fire deprecated code to emulate old version to ensure index backwards compat.
Related: we deprecate old analysis components and eventually remove them.

To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
if you don't specify a version in your solrconfig, it defaults to 2.4 though.

However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.

Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.

I propose:
# in trunk: we make the solrconfig luceneMatchVersion mandatory.
This is simple: Uwe already has a method that will error out if its not present, we just use that.
# in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
# in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
# in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.


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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Search Discussions

  • Robert Muir (JIRA) at Nov 30, 2010 at 1:56 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir updated SOLR-2259:
    ------------------------------

    Attachment: SOLR-2259.patch

    here is a patch for part 1. This patch is intended for trunk only.

    it adds the required matchVersion, where missing, to any test/example configs, and makes it mandatory.

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Uwe Schindler (JIRA) at Nov 30, 2010 at 2:20 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965227#action_12965227 ]

    Uwe Schindler commented on SOLR-2259:
    -------------------------------------

    +1, thanks for the work!

    Your ideas sound great, we should add a general framework for these warnings in 3.x, not sure what would be the best idea to even generate good messages. Ideally the code could print @deprecated warnings, but those are not available to runtime :-)
    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Nov 30, 2010 at 2:30 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965232#action_12965232 ]

    Robert Muir commented on SOLR-2259:
    -----------------------------------

    bq. we should add a general framework for these warnings in 3.x

    for #2, i think we might have to add a arg to the config method "warnIfDefaulting" or something...
    regardless of whether its missing, or actually specified as 2.9.x, we should warn that its using old emulation as a default too, so i think we should do an onOrAfter check.

    i think instance #3 can be addressed easiest with an onOrAfter check in the BaseTokenStreamFactory.assureMatchVersion, that prints the classname etc, since its the superclass
    for all tokenstreams.

    for #4, there are really not that many deprecated TokenStreamFactories, just a few, so i think
    it might be easiest to just add the log call to each for now...

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Nov 30, 2010 at 2:58 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir updated SOLR-2259:
    ------------------------------

    Attachment: SOLR-2259.patch

    here's the updated patch, that uses the ant property $tests.luceneMatchVersion
    in all of the configs.

    if this sysprop isnt set (e.g. IDE) then it will use LUCENE_CURRENT,
    which will emit a warning, but probably good for casual running of tests from an IDE.

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Dec 1, 2010 at 12:56 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965675#action_12965675 ]

    Robert Muir commented on SOLR-2259:
    -----------------------------------

    I committed the patch for part 1 to trunk in revision 1040982: the luceneMatchVersion parameter is mandatory,
    and all tests files have it (its driven by the existing ant sysprop $tests.luceneMatchVersion).

    I backported just the versioning of the tests files to branch-3x in rev 1040986: this is just for consistency to make
    merging of any changes to these files easier, etc.

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Dec 16, 2010 at 1:56 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir updated SOLR-2259:
    ------------------------------

    Attachment: SOLR-2259part2.patch

    here is a patch for branch_3x for part 2.

    it warns if you are missing the luceneMatchVersion param in your config,
    informing you that its emulating Lucene 2.4 and that this emulation is deprecated,
    and that this parameter will be mandatory in 4.0

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259part2.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Dec 16, 2010 at 5:27 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972150#action_12972150 ]

    Robert Muir commented on SOLR-2259:
    -----------------------------------

    I committed part 2 in revision 1050064.
    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259part2.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Dec 26, 2010 at 4:26 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir updated SOLR-2259:
    ------------------------------

    Attachment: SOLR-2259_part3.patch

    here's a patch for part3.
    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259_part3.patch, SOLR-2259part2.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Jan 16, 2011 at 6:14 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir reassigned SOLR-2259:
    ---------------------------------

    Assignee: Robert Muir
    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Assignee: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259_part3.patch, SOLR-2259part2.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Jan 17, 2011 at 12:48 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir updated SOLR-2259:
    ------------------------------

    Attachment: SOLR-2259part4.patch

    Here is the patch for the last part, part 4.

    I added a warnDeprecated() helper method to the base class,
    and added messages for all deprecated classes in trunk.

    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Assignee: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259_part3.patch, SOLR-2259part2.patch, SOLR-2259part4.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org
  • Robert Muir (JIRA) at Jan 17, 2011 at 6:40 pm
    [ https://issues.apache.org/jira/browse/SOLR-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

    Robert Muir resolved SOLR-2259.
    -------------------------------

    Resolution: Fixed
    Improve analyzer/version handling in Solr
    -----------------------------------------

    Key: SOLR-2259
    URL: https://issues.apache.org/jira/browse/SOLR-2259
    Project: Solr
    Issue Type: Task
    Reporter: Robert Muir
    Assignee: Robert Muir
    Fix For: 3.1, 4.0

    Attachments: SOLR-2259.patch, SOLR-2259.patch, SOLR-2259_part3.patch, SOLR-2259part2.patch, SOLR-2259part4.patch


    We added Version for backwards compatibility support in Lucene.
    We use this to fire deprecated code to emulate old version to ensure index backwards compat.
    Related: we deprecate old analysis components and eventually remove them.
    To hook into Solr, at first it defaulted to Version 2.4 emulation everywhere, with the example having the latest.
    if you don't specify a version in your solrconfig, it defaults to 2.4 though.
    However, as of LUCENE-2781 2.4 is removed: but users with old configs that don't specify a version should not be silently "upgraded" to the Version 3.0 emulation... this is bad.
    Additionally, when users are using deprecated emulation or using deprecated factories they might not know it, and it might come as a surprise if they upgrade, especially if they arent looking at java apis or java code.
    I propose:
    # in trunk: we make the solrconfig luceneMatchVersion mandatory.
    This is simple: Uwe already has a method that will error out if its not present, we just use that.
    # in 3.x: we warn if you don't specify luceneMatchVersion in solrconfig: telling you that its going to be required in 4.0 and that you are defaulting to 2.4 emulation.
    For example: Warning: luceneMatchVersion is not specified in solrconfig.xml. Defaulting to 2.4 emulation. You should at some point declare and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0. This parameter will be mandatory in 4.0.
    # in 3.x,trunk: we warn if you are using a deprecated matchVersion constant somewhere in general, even for a specific tokenizer, telling you that you need to at some point reindex with a current version before you can move to the next release.
    For example: Warning: you are using 2.4 emulation, at some point you need to bump and reindex to at least 3.0, because 2.4 emulation is deprecated in 3.x and will be removed in 4.0
    # in 3.x,trunk: we warn if you are using a deprecated TokenStreamFactory so that you know its going to be removed.
    For example: Warning: the ISOLatin1FilterFactory is deprecated and will be removed in the next release. You should migrate to ASCIIFoldingFilterFactory.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
    For additional commands, e-mail: dev-help@lucene.apache.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categorieslucene
postedNov 30, '10 at 1:54p
activeJan 17, '11 at 6:40p
posts12
users1
websitelucene.apache.org

1 user in discussion

Robert Muir (JIRA): 12 posts

People

Translate

site design / logo © 2021 Grokbase