Solr
  1. Solr
  2. SOLR-3251 dynamically add fields to schema
  3. SOLR-4658

In preparation for dynamic schema modification via REST API, add a "managed" schema facility

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3, 5.0
    • Component/s: Schema and Analysis
    • Labels:
      None

      Description

      The idea is to have a set of configuration items in solrconfig.xml:

      <schema managed="true" mutable="true" managedSchemaResourceName="managed-schema"/>
      

      It will be a precondition for future dynamic schema modification APIs that mutable="true". solrconfig.xml parsing will fail if mutable="true" but managed="false".

      When managed="true", and the resource named in managedSchemaResourceName doesn't exist, Solr will automatically upgrade the schema to "managed": the non-managed schema resource (typically schema.xml) is parsed and then persisted at managedSchemaResourceName under $solrHome/$collectionOrCore/conf/, or on ZooKeeper at /configs/$configName/, and the non-managed schema resource is renamed by appending .bak, e.g. schema.xml.bak.

      Once the upgrade has taken place, users can get the full schema from the /schema?wt=schema.xml REST API, and can use this as the basis for modifications which can then be used to manually downgrade back to non-managed schema: put the schema.xml in place, then add <schema managed="false"/> to solrconfig.xml (or remove the whole <schema/> element, since managed="false" is the default).

      If users take no action, then Solr behaves the same as always: the example solrconfig.xml will include <schema managed="false" ...>.

      For a discussion of rationale for this feature, see Chris Hostetter's post to the solr-user mailing list in the thread "Dynamic schema design: feedback requested" http://markmail.org/message/76zj24dru2gkop7b:

      Ignoring for a moment what format is used to persist schema information, I
      think it's important to have a conceptual distinction between "data" that
      is managed by applications and manipulated by a REST API, and "config"
      that is managed by the user and loaded by solr on init – or via an
      explicit "reload config" REST API.

      Past experience with how users percieve(d) solr.xml has heavily reinforced
      this opinion: on one hand, it's a place users must specify some config
      information – so people wnat to be able to keep it in version control
      with other config files. On the other hand it's a "live" data file that
      is rewritten by solr when cores are added. (God help you if you want do a
      rolling deploy a new version of solr.xml where you've edited some of the
      config values while simultenously clients are creating new SolrCores)

      As we move forward towards having REST APIs that treat schema information
      as "data" that can be manipulated, I anticipate the same types of
      confusion, missunderstanding, and grumblings if we try to use the same
      pattern of treating the existing schema.xml (or some new schema.json) as a
      hybrid configs & data file. "Edit it by hand if you want, the /schema/*
      REST API will too!" ... Even assuming we don't make any of the same
      technical mistakes that have caused problems with solr.xml round tripping
      in hte past (ie: losing comments, reading new config options that we
      forget to write back out, etc...) i'm fairly certain there is still going
      to be a lot of things that will loook weird and confusing to people.

      (XML may bave been designed to be both "human readable & writable" and
      "machine readable & writable", but practically speaking it's hard have a
      single XML file be "machine and human readable & writable")

      I think it would make a lot of sense – not just in terms of
      implementation but also for end user clarity – to have some simple,
      straightforward to understand caveats about maintaining schema
      information...

      1) If you want to keep schema information in an authoritative config file
      that you can manually edit, then the /schema REST API will be read only.

      2) If you wish to use the /schema REST API for read and write operations,
      then schema information will be persisted under the covers in a data store
      whose format is an implementation detail just like the index file format.

      3) If you are using a schema config file and you wish to switch to using
      the /schema REST API for managing schema information, there is a
      tool/command/API you can run to so.

      4) if you are using the /schema REST API for managing schema information,
      and you wish to switch to using a schema config file, there is a
      tool/command/API you can run to export the schema info if a config file
      format.

      ...wether of not the "under the covers in a data store" used by the REST
      API is JSON, or some binary data, or an XML file just schema.xml w/o
      whitespace/comments should be an implementation detail. Likewise is the
      question of wether some new config file formats are added – it shouldn't
      matter.

      If it's config it's config and the user owns it.
      If it's data it's data and the system owns it.

      : is the risk they take if they want to manually edit it - it's no
      : different than today when you edit the file and do a Core reload or
      : something. I think we can improve some validation stuff around that, but
      : it doesn't seem like a show stopper to me.

      The new risk is multiple "actors" (both the user, and Solr) editing the
      file concurrently, and info that might be lost due to Solr reading the
      file, manpulating internal state, and then writing the file back out.

      Eg: User hand edits may be lost if they happen on disk during Solr's
      internal manpulation of data. API edits may be reflected in the internal
      state, but lost if the User writes the file directly and then does a core
      reload, etc....

      : At a minimum, I think the user should be able to start with a hand
      : modified file. Many people heavily modify the example schema to fit
      : their use case. If you have to start doing that by making 50 rest API
      : calls, that's pretty rough. Once you get your schema nice and happy, you
      : might script out those rest calls, but initially, it's much
      : faster/easier to whack the schema into place in a text editor IMO.

      I don't think there is any disagreement about that. The ability to say
      "my schema is a config file and i own it" should always exist (remove
      it over my dead body)

      The question is what trade offs to expect/require for people who would
      rather use an API to manipulate these things – i don't think it's
      unreasable to say "if you would like to manipulate the schema using an
      API, then you give up the ability to manipulate it as a config file on
      disk"

      ("if you want the /schema API to drive your car, you have to take your
      foot of hte pedals and let go of the steering wheel")

      1. SOLR-4658-fix-serialization.patch
        35 kB
        Steve Rowe
      2. SOLR-4658.patch
        96 kB
        Steve Rowe
      3. SOLR-4658.patch
        79 kB
        Steve Rowe

        Activity

        Hide
        Steve Rowe added a comment -

        Patch implementing the idea.

        This makes the IndexSchema constructor private, and adds a factory method named create(), which manages the upgrade-to-managed-schema process when necessary.

        The persistence format is kept as XML. A comment at the top says:

        <!-- Solr managed schema - automatically generated - DO NOT EDIT -->
        

        This patch also add a method to core.Config to test for unexpected element attributes when parsing solrconfig.xml: complainAboutUnknownAttributes(). I'm only using it for the <schema/> tag at this point, but it should be useful for any other config elements that have a known fixed set of attributes.

        Tests added for SolrCloud and standalone modes.

        I think it's ready to go.

        Show
        Steve Rowe added a comment - Patch implementing the idea. This makes the IndexSchema constructor private, and adds a factory method named create() , which manages the upgrade-to-managed-schema process when necessary. The persistence format is kept as XML. A comment at the top says: <!-- Solr managed schema - automatically generated - DO NOT EDIT --> This patch also add a method to core.Config to test for unexpected element attributes when parsing solrconfig.xml : complainAboutUnknownAttributes() . I'm only using it for the <schema/> tag at this point, but it should be useful for any other config elements that have a known fixed set of attributes. Tests added for SolrCloud and standalone modes. I think it's ready to go.
        Hide
        Robert Muir added a comment -

        It seems a little wierd to tie in all this zookeeper etc stuff into indexschema, and i'm still trying to figure out the mutable/managed stuff.

        If the goal is to have multiple implementations of indexschema (immutable ones backed by human edited files, mutable ones saved to some opaque "database" that can be edited by REST), then why not make IndexSchema abstract and pluggable from solrconfig.xml like anything else?

        Show
        Robert Muir added a comment - It seems a little wierd to tie in all this zookeeper etc stuff into indexschema, and i'm still trying to figure out the mutable/managed stuff. If the goal is to have multiple implementations of indexschema (immutable ones backed by human edited files, mutable ones saved to some opaque "database" that can be edited by REST), then why not make IndexSchema abstract and pluggable from solrconfig.xml like anything else?
        Hide
        Steve Rowe added a comment -

        It seems a little wierd to tie in all this zookeeper etc stuff into indexschema

        Well, since it's only used by IndexSchema, it seemed like the logical location. Do you have an alternative suggestion?

        If the goal is to have multiple implementations of indexschema (immutable ones backed by human edited files, mutable ones saved to some opaque "database" that can be edited by REST), then why not make IndexSchema abstract and pluggable from solrconfig.xml like anything else?

        I imagine you're thinking of a hierarchy like:

        • IndexSchema
          • MutableIndexSchema
            • MutableZooKeeperIndexSchema
            • MutableLocalIndexSchema
            • Mutable<Whatever>IndexSchema
            • ...
          • ImmutableIndexSchema
            • ImmutableZooKeeperIndexSchema
            • ImmutableLocalIndexSchema
            • Mutable<Whatever>IndexSchema
            • ...

        Is that right?

        Then solrconfig.xml config could be something like

        <schema managed="true|false" storage="local|zookeeper|whatever" mutable="true|false" managedSchemaResourceName="..."/>

        And the implementation could be chosen using SPI or something like it.

        One problem I see with this: the decision about the storage location for configs is made elsewhere - it would definitely be an issue if people chose e.g. managed="true" storage="local" in SolrCloud mode.

        Or maybe I've misrepresented what you had in mind, Robert?

        Show
        Steve Rowe added a comment - It seems a little wierd to tie in all this zookeeper etc stuff into indexschema Well, since it's only used by IndexSchema, it seemed like the logical location. Do you have an alternative suggestion? If the goal is to have multiple implementations of indexschema (immutable ones backed by human edited files, mutable ones saved to some opaque "database" that can be edited by REST), then why not make IndexSchema abstract and pluggable from solrconfig.xml like anything else? I imagine you're thinking of a hierarchy like: IndexSchema MutableIndexSchema MutableZooKeeperIndexSchema MutableLocalIndexSchema Mutable<Whatever>IndexSchema ... ImmutableIndexSchema ImmutableZooKeeperIndexSchema ImmutableLocalIndexSchema Mutable<Whatever>IndexSchema ... Is that right? Then solrconfig.xml config could be something like <schema managed="true|false" storage="local|zookeeper|whatever" mutable="true|false" managedSchemaResourceName="..."/> And the implementation could be chosen using SPI or something like it. One problem I see with this: the decision about the storage location for configs is made elsewhere - it would definitely be an issue if people chose e.g. managed="true" storage="local" in SolrCloud mode. Or maybe I've misrepresented what you had in mind, Robert?
        Hide
        Robert Muir added a comment -

        yeah I think i didnt communicate it well enough.

        I guess i was thinking:

        <schema class="FooSchema" someOptionThatMightOnlyMakeSenseToFoo="true"/>
        

        So IndexSchema becomes abstract and loaded just like other plugins, versus being a "wonder-do-it-all" class. It would also
        have the advantage of not having a bunch of options that have illegal combinations (e.g. managed+mutable)

        Finally it makes it extensible: if someone wants to make their own impl that is powered by microsoft access .MDB files then
        they can do so.

        (Also i think it would make backwards compatibility possible in case something changes in drastic ways).

        Show
        Robert Muir added a comment - yeah I think i didnt communicate it well enough. I guess i was thinking: <schema class= "FooSchema" someOptionThatMightOnlyMakeSenseToFoo= " true " /> So IndexSchema becomes abstract and loaded just like other plugins, versus being a "wonder-do-it-all" class. It would also have the advantage of not having a bunch of options that have illegal combinations (e.g. managed+mutable) Finally it makes it extensible: if someone wants to make their own impl that is powered by microsoft access .MDB files then they can do so. (Also i think it would make backwards compatibility possible in case something changes in drastic ways).
        Hide
        Robert Muir added a comment -

        And maybe its not that the whole class need be abstract, just the implicit factory thats currently done with static methods.

        So it could have load/save or something simple like that. The default one today wouldnt have any options at all and would throw UOE on save().

        Show
        Robert Muir added a comment - And maybe its not that the whole class need be abstract, just the implicit factory thats currently done with static methods. So it could have load/save or something simple like that. The default one today wouldnt have any options at all and would throw UOE on save().
        Hide
        Steve Rowe added a comment -

        So is my class hierarchy what you were thinking of? If not, what would FooSchema be to support the current functionality?

        I was thinking that requiring the user to know the class name for the combination of options they want would be a bit much. In particular, it might be useful to switch between mutable and immutable without changing anything else, and making the user change the class name for this seems like overkill.

        Show
        Steve Rowe added a comment - So is my class hierarchy what you were thinking of? If not, what would FooSchema be to support the current functionality? I was thinking that requiring the user to know the class name for the combination of options they want would be a bit much. In particular, it might be useful to switch between mutable and immutable without changing anything else, and making the user change the class name for this seems like overkill.
        Hide
        Steve Rowe added a comment -

        Robert, making your suggestions concrete, if the factory stuff is pulled out of IndexSchema, then config could be:

        <schemaFactory class="ClassicIndexSchemaFactory"/> <!-- current behavior -->
        <schemaFactory class="ManagedIndexSchemaFactory" mutable="true|false" managedSchemaResourceName="managed-schema"/>
        <schemaFactory class="MSAccessIndexSchemaFactory" whatever="..."/>
        ...
        
        Show
        Steve Rowe added a comment - Robert, making your suggestions concrete, if the factory stuff is pulled out of IndexSchema, then config could be: <schemaFactory class= "ClassicIndexSchemaFactory" /> <!-- current behavior --> <schemaFactory class= "ManagedIndexSchemaFactory" mutable= "true|false" managedSchemaResourceName= "managed-schema" /> <schemaFactory class= "MSAccessIndexSchemaFactory" whatever= "..." /> ...
        Hide
        Robert Muir added a comment -

        Robert, making your suggestions concrete, if the factory stuff is pulled out of IndexSchema, then config could be:

        Steve: thats exactly what i was thinking of!

        Show
        Robert Muir added a comment - Robert, making your suggestions concrete, if the factory stuff is pulled out of IndexSchema, then config could be: Steve: thats exactly what i was thinking of!
        Hide
        Robert Muir added a comment -

        and it would also be a bonus in the future if somehow the backwards cruft existing in various FieldType etc
        apis (e.g. defaults and so on) were factored into the Classic guy to keep those apis simpler...

        Show
        Robert Muir added a comment - and it would also be a bonus in the future if somehow the backwards cruft existing in various FieldType etc apis (e.g. defaults and so on) were factored into the Classic guy to keep those apis simpler...
        Hide
        Steve Rowe added a comment -

        This patch converts the IndexSchema config in solrconfig.xml to be plugin-based, and moves the static factory methods out of IndexSchema into classes ClassicIndexSchemaFactory and ManagedIndexSchemaFactory. Here's the new config for managed schema:

        <schemaFactory class="ManagedIndexSchemaFactory">
          <bool name="mutable">true</bool>
          <str name="managedSchemaResourceName">managed-schema</str>
        </schemaFactory>
        
        Show
        Steve Rowe added a comment - This patch converts the IndexSchema config in solrconfig.xml to be plugin-based, and moves the static factory methods out of IndexSchema into classes ClassicIndexSchemaFactory and ManagedIndexSchemaFactory. Here's the new config for managed schema: <schemaFactory class= "ManagedIndexSchemaFactory" > <bool name= "mutable" > true </bool> <str name= "managedSchemaResourceName" > managed-schema </str> </schemaFactory>
        Hide
        Robert Muir added a comment -

        I like it much better! I think this will be more flexible for the future.

        Can we keep IndexSchema's ctor public so that its possible to really make one of these plugins?

        -  public IndexSchema(SolrConfig solrConfig, String name, InputSource is) {
        +  IndexSchema(SolrConfig solrConfig, String name, InputSource is) {
        

        Thanks Steve!

        Show
        Robert Muir added a comment - I like it much better! I think this will be more flexible for the future. Can we keep IndexSchema's ctor public so that its possible to really make one of these plugins? - public IndexSchema(SolrConfig solrConfig, String name, InputSource is) { + IndexSchema(SolrConfig solrConfig, String name, InputSource is) { Thanks Steve!
        Hide
        Steve Rowe added a comment -

        Can we keep IndexSchema's ctor public so that its possible to really make one of these plugins?

        Yes, I'll do that.

        Show
        Steve Rowe added a comment - Can we keep IndexSchema's ctor public so that its possible to really make one of these plugins? Yes, I'll do that.
        Hide
        Steve Rowe added a comment -

        Committed to trunk r1463182 and branch_4x r1463193.

        Thanks Robert!

        Show
        Steve Rowe added a comment - Committed to trunk r1463182 and branch_4x r1463193. Thanks Robert!
        Hide
        yuanyun.cn added a comment -

        Steve, Thanks for your excellent work.
        I met one small issue when use this feature: in our schema, we define one fieldtype, it has one tokenizer: MyPathHierarchyTokenizerFactory which in the package org.apache.lucene.analysis. – This is not good, but the factory class is in the package a long time ago.

         
        <fieldType name="text_path" class="solr.TextField" positionIncrementGap="100">
        	<analyzer>
        		<tokenizer class="org.apache.lucene.analysis.MyPathHierarchyTokenizerFactory" delimiter="\" replace="/"/>
        	</analyzer>
        </fieldType>
        

        After upgrade, it shorten the name to solr.MyPathHierarchyTokenizerFactory due to org.apache.solr.schema.FieldType.getShortName(String).
        private static final Pattern SHORTENABLE_PACKAGE_PATTERN = Pattern.compile("org\\.apache\\.(?:lucene\\.analysis(?=.).*|solr\\.(?:analysis|schema))
        .([^.]+)$");

        Then later it will fail with follwing error when I restart my solr server,
        Caused by: org.apache.solr.common.SolrException: Error loading class 'solr.MyPathHierarchyTokenizerFactory'
        at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:440)

        This is because in SolrResourceLoader.findClass, it will try to load the class in sub packages of org.apache.solr. Can't find it, so throw ClassNotFoundException.
        base="org.apache.solr";
        String name = base + '.' + subpackage + newName;
        return clazz = Class.forName(name,true,classLoader).asSubclass(expectedType);

        I think maybe we can SHORTENABLE_PACKAGE_PATTERN: Pattern.compile("org\\.apache\\.(?:solr\\.(?:analysis|schema))
        .([^.]+)$");
        After change SHORTENABLE_PACKAGE_PATTERN like above, it works for me now.

        Show
        yuanyun.cn added a comment - Steve, Thanks for your excellent work. I met one small issue when use this feature: in our schema, we define one fieldtype, it has one tokenizer: MyPathHierarchyTokenizerFactory which in the package org.apache.lucene.analysis. – This is not good, but the factory class is in the package a long time ago. <fieldType name= "text_path" class= "solr.TextField" positionIncrementGap= "100" > <analyzer> <tokenizer class= "org.apache.lucene.analysis.MyPathHierarchyTokenizerFactory" delimiter= "\" replace= "/" /> </analyzer> </fieldType> After upgrade, it shorten the name to solr.MyPathHierarchyTokenizerFactory due to org.apache.solr.schema.FieldType.getShortName(String). private static final Pattern SHORTENABLE_PACKAGE_PATTERN = Pattern.compile("org\\.apache\\.(?:lucene\\.analysis(?=.).*|solr\\.(?:analysis|schema)) .( [^.] +)$"); Then later it will fail with follwing error when I restart my solr server, Caused by: org.apache.solr.common.SolrException: Error loading class 'solr.MyPathHierarchyTokenizerFactory' at org.apache.solr.core.SolrResourceLoader.findClass(SolrResourceLoader.java:440) This is because in SolrResourceLoader.findClass, it will try to load the class in sub packages of org.apache.solr. Can't find it, so throw ClassNotFoundException. base="org.apache.solr"; String name = base + '.' + subpackage + newName; return clazz = Class.forName(name,true,classLoader).asSubclass(expectedType); I think maybe we can SHORTENABLE_PACKAGE_PATTERN: Pattern.compile("org\\.apache\\.(?:solr\\.(?:analysis|schema)) .( [^.] +)$"); After change SHORTENABLE_PACKAGE_PATTERN like above, it works for me now.
        Hide
        Robert Muir added a comment -

        I mentioned this same bug as it applies to similarities on the dev list a week or so ago!

        Show
        Robert Muir added a comment - I mentioned this same bug as it applies to similarities on the dev list a week or so ago!
        Hide
        Steve Rowe added a comment -

        Hi yuanyun,

        Thanks for the bug report.

        The problem isn't that SHORTENABLE_PACKAGE_PATTERN includes factories under org.apache.lucene.analysis - most of the shared Lucene/Solr analysis factories live there now - but rather that users can use the same package for their own code, which is what you've done.

        The issue is serialization: as currently written, the user's class="whatever" is lost, and the serialization code attempts to reconstitute it on output. I think the fix is to stop guessing what it should be, and just reuse the exact string supplied by the user in the original file when persisting the schema.

        I'll make a patch.

        Show
        Steve Rowe added a comment - Hi yuanyun, Thanks for the bug report. The problem isn't that SHORTENABLE_PACKAGE_PATTERN includes factories under org.apache.lucene.analysis - most of the shared Lucene/Solr analysis factories live there now - but rather that users can use the same package for their own code, which is what you've done. The issue is serialization: as currently written, the user's class="whatever" is lost, and the serialization code attempts to reconstitute it on output. I think the fix is to stop guessing what it should be, and just reuse the exact string supplied by the user in the original file when persisting the schema. I'll make a patch.
        Hide
        Steve Rowe added a comment - - edited

        I mentioned this same bug as it applies to similarities on the dev list a week or so ago!

        Yes, Robert Muir, you did, and my fix at the time was insufficient, since it still didn't properly handle third-party Similarity implementations located under org.apache.lucene or org.apache.solr.

        The attached patch fixes class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories, and includes tests making sure that names are preserved in both shortened and fully qualified original forms.

        There is a similar/related issue with luceneMatchVersion args on analysis factories, where the serialized form explicitly includes default match version in cases where it was not specified on the original form. The patch fixes this to only serialize the luceneMatchVersion when it's explicitly present on the original, and includes tests checking that present and absent args are kept as-is. (Persisting the default match version will be a problem when the default match version changes, because the persisted version(s) will no longer track the default version.)

        Also part of this patch is a factory for MockTokenFilter.

        I'll commit shortly.

        Show
        Steve Rowe added a comment - - edited I mentioned this same bug as it applies to similarities on the dev list a week or so ago! Yes, Robert Muir , you did, and my fix at the time was insufficient, since it still didn't properly handle third-party Similarity implementations located under org.apache.lucene or org.apache.solr. The attached patch fixes class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories, and includes tests making sure that names are preserved in both shortened and fully qualified original forms. There is a similar/related issue with luceneMatchVersion args on analysis factories, where the serialized form explicitly includes default match version in cases where it was not specified on the original form. The patch fixes this to only serialize the luceneMatchVersion when it's explicitly present on the original, and includes tests checking that present and absent args are kept as-is. (Persisting the default match version will be a problem when the default match version changes, because the persisted version(s) will no longer track the default version.) Also part of this patch is a factory for MockTokenFilter. I'll commit shortly.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] sarowe
        http://svn.apache.org/viewvc?view=revision&revision=1466720

        SOLR-4658:

        • Fix class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories: persisted class names' original forms are preserved in both shortened form (e.g. 'solr.TextField') and fully qualified form (e.g. 'org.apache.solr.schema.TextField')
        • luceneMatchVersion on analysis factories is now persisted only when explicitly specified in the original; previously the default value was persisted when it was absent in the original
        • Add MockTokenFilterFactory
        Show
        Commit Tag Bot added a comment - [trunk commit] sarowe http://svn.apache.org/viewvc?view=revision&revision=1466720 SOLR-4658 : Fix class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories: persisted class names' original forms are preserved in both shortened form (e.g. 'solr.TextField') and fully qualified form (e.g. 'org.apache.solr.schema.TextField') luceneMatchVersion on analysis factories is now persisted only when explicitly specified in the original; previously the default value was persisted when it was absent in the original Add MockTokenFilterFactory
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] sarowe
        http://svn.apache.org/viewvc?view=revision&revision=1466724

        SOLR-4658:

        • Fix class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories: persisted class names' original forms are preserved in both shortened form (e.g. 'solr.TextField') and fully qualified form (e.g. 'org.apache.solr.schema.TextField')
        • luceneMatchVersion on analysis factories is now persisted only when explicitly specified in the original; previously the default value was persisted when it was absent in the original
        • Add MockTokenFilterFactory
        Show
        Commit Tag Bot added a comment - [branch_4x commit] sarowe http://svn.apache.org/viewvc?view=revision&revision=1466724 SOLR-4658 : Fix class name shortening issues, for SimilarityFactory's, FieldType's, and analysis factories: persisted class names' original forms are preserved in both shortened form (e.g. 'solr.TextField') and fully qualified form (e.g. 'org.apache.solr.schema.TextField') luceneMatchVersion on analysis factories is now persisted only when explicitly specified in the original; previously the default value was persisted when it was absent in the original Add MockTokenFilterFactory
        Hide
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.

          People

          • Assignee:
            Steve Rowe
            Reporter:
            Steve Rowe
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development