Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.4, Trunk
    • Component/s: Schema and Analysis
    • Labels:
      None

      Description

      Per SOLR-4898, adding copy field support. Should be simply a new parameter to the PUT/POST with the name of the target to copy to.

      1. SOLR-5010.patch
        10 kB
        Grant Ingersoll
      2. SOLR-5010.patch
        11 kB
        Grant Ingersoll
      3. SOLR-5010.patch
        16 kB
        Grant Ingersoll
      4. SOLR-5010-copyFields.patch
        9 kB
        Grant Ingersoll
      5. SOLR-5010-copyFields.patch
        18 kB
        Grant Ingersoll
      6. SOLR-5010-copyFields.patch
        19 kB
        Grant Ingersoll
      7. SOLR-5010-copyFields.patch
        23 kB
        Grant Ingersoll
      8. json_regex.patch
        3 kB
        Yonik Seeley

        Activity

        Hide
        Grant Ingersoll added a comment -

        First start at this, pretty straightforward, but needs more tests.

        Adds an option called copyFields, which can take a comma separated list of targets to copy the source to. See the TestManagedSchemaFieldResource for an example.

        Show
        Grant Ingersoll added a comment - First start at this, pretty straightforward, but needs more tests. Adds an option called copyFields, which can take a comma separated list of targets to copy the source to. See the TestManagedSchemaFieldResource for an example.
        Hide
        Grant Ingersoll added a comment -

        Fix PUT option and add a test for it.

        I think this is ready to go, but going to wait for others to double check, as I am not sure on how the hand off of the old schema to the new schema is managed and if adding the registerCopyField where I did is the right thing to do.

        Show
        Grant Ingersoll added a comment - Fix PUT option and add a test for it. I think this is ready to go, but going to wait for others to double check, as I am not sure on how the hand off of the old schema to the new schema is managed and if adding the registerCopyField where I did is the right thing to do.
        Hide
        Grant Ingersoll added a comment -

        Looking at this more, I'm not sure this patch is right in terms of synchronization and persistence of the schema, so I'm going to keep working on it.

        Show
        Grant Ingersoll added a comment - Looking at this more, I'm not sure this patch is right in terms of synchronization and persistence of the schema, so I'm going to keep working on it.
        Hide
        Grant Ingersoll added a comment -

        Moves work into the ManagedIndexSchema.addFields, so that it is properly sync'd and persisted

        Show
        Grant Ingersoll added a comment - Moves work into the ManagedIndexSchema.addFields, so that it is properly sync'd and persisted
        Hide
        Grant Ingersoll added a comment -

        I plan on committing this in the AM (Monday, 7/8)

        Show
        Grant Ingersoll added a comment - I plan on committing this in the AM (Monday, 7/8)
        Hide
        ASF subversion and git services added a comment -

        Commit 1500737 from Grant Ingersoll
        [ https://svn.apache.org/r1500737 ]

        SOLR-5010: add copy field support to the REST API

        Show
        ASF subversion and git services added a comment - Commit 1500737 from Grant Ingersoll [ https://svn.apache.org/r1500737 ] SOLR-5010 : add copy field support to the REST API
        Hide
        ASF subversion and git services added a comment -

        Commit 1500744 from Grant Ingersoll
        [ https://svn.apache.org/r1500744 ]

        SOLR-5010: merge from trunk

        Show
        ASF subversion and git services added a comment - Commit 1500744 from Grant Ingersoll [ https://svn.apache.org/r1500744 ] SOLR-5010 : merge from trunk
        Hide
        Steve Rowe added a comment -

        Grant Ingersoll, I think your copyFields implementation is missing an important piece of functionality: copying one existing field to another, without adding any new fields, i.e. PUT to /schema/copyFields

        In fact, I'm not convinced that tacking copyFields directives onto /schema/fields is the right way to go, since we have to have the ability to PUT to /schema/copyFields for the not-adding-fields case anyway: it needlessly complicates the API and the code.

        I'll work on a patch.

        Show
        Steve Rowe added a comment - Grant Ingersoll , I think your copyFields implementation is missing an important piece of functionality: copying one existing field to another, without adding any new fields, i.e. PUT to /schema/copyFields In fact, I'm not convinced that tacking copyFields directives onto /schema/fields is the right way to go, since we have to have the ability to PUT to /schema/copyFields for the not-adding-fields case anyway: it needlessly complicates the API and the code. I'll work on a patch.
        Hide
        Grant Ingersoll added a comment -

        First part of this is in: can setup copy fields when creating new fields. Next would be to add new copy fields for existing fields.

        Show
        Grant Ingersoll added a comment - First part of this is in: can setup copy fields when creating new fields. Next would be to add new copy fields for existing fields.
        Hide
        Grant Ingersoll added a comment -

        In fact, I'm not convinced that tacking copyFields directives onto /schema/fields is the right way to go, since we have to have the ability to PUT to /schema/copyFields for the not-adding-fields case anyway: it needlessly complicates the API and the code.

        We can refactor it to be shared (although it is pretty minimal amount of code) across fields and /copyFields. I do think being able to specify it when adding is useful, as it can all be done as part of that single call and is very straightforward to do.

        Show
        Grant Ingersoll added a comment - In fact, I'm not convinced that tacking copyFields directives onto /schema/fields is the right way to go, since we have to have the ability to PUT to /schema/copyFields for the not-adding-fields case anyway: it needlessly complicates the API and the code. We can refactor it to be shared (although it is pretty minimal amount of code) across fields and /copyFields. I do think being able to specify it when adding is useful, as it can all be done as part of that single call and is very straightforward to do.
        Hide
        Grant Ingersoll added a comment - - edited

        Adds a post to /schema/copyfields to support adding fields directly.

        Didn't do any refactoring of shared code yet, as it feels like we should do this after 4.4 as there are multiple places to do this that go beyond this patch

        Show
        Grant Ingersoll added a comment - - edited Adds a post to /schema/copyfields to support adding fields directly. Didn't do any refactoring of shared code yet, as it feels like we should do this after 4.4 as there are multiple places to do this that go beyond this patch
        Hide
        Steve Rowe added a comment -

        Grant, a few comments about your most recent patch:

        1. This comment in ManagedIndexSchema.addCopyFields() should be changed to reflect its context:

        // even though fields is volatile, we need to synchronize to avoid two addFields
        // happening concurrently (and ending up missing one of them)
        

        to something like "we need to synchronize to avoid two addCopyFields happening concurrently (and ending up missing one of them)"

        2. In CopyFieldsCollectionResource.post(), the loop over the copy field directives will throw away all but the last directive, because the directives are each added to oldSchema, which is never updated:

        ManagedIndexSchema oldSchema = (ManagedIndexSchema) getSchema();
        for (Map<String,Object> map : list) {
        [...]
          if (splits != null && splits.length > 0){
            for (int i = 0; i < splits.length; i++) {
              destinationSet.add(splits[i].trim());
            }
            IndexSchema newSchema = oldSchema.addCopyFields(fieldName, destinationSet);
            if (newSchema != null) {
              getSolrCore().setLatestSchema(newSchema);
            }
          }
        

        Maybe ManagedIndexSchema.addCopyFields() could accept a Map<String,Set<String>>, containing all copyField directives, instead of the current one at a time? That would mirror behavior of ManagedIndexSchema.addFields(), and would make it so that the schema would only need to be modified/persisted once; the above-described problem would then disappear.

        3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case.

        Show
        Steve Rowe added a comment - Grant, a few comments about your most recent patch: 1. This comment in ManagedIndexSchema.addCopyFields() should be changed to reflect its context: // even though fields is volatile , we need to synchronize to avoid two addFields // happening concurrently (and ending up missing one of them) to something like "we need to synchronize to avoid two addCopyFields happening concurrently (and ending up missing one of them)" 2. In CopyFieldsCollectionResource.post(), the loop over the copy field directives will throw away all but the last directive, because the directives are each added to oldSchema , which is never updated: ManagedIndexSchema oldSchema = (ManagedIndexSchema) getSchema(); for (Map< String , Object > map : list) { [...] if (splits != null && splits.length > 0){ for ( int i = 0; i < splits.length; i++) { destinationSet.add(splits[i].trim()); } IndexSchema newSchema = oldSchema.addCopyFields(fieldName, destinationSet); if (newSchema != null ) { getSolrCore().setLatestSchema(newSchema); } } Maybe ManagedIndexSchema.addCopyFields() could accept a Map<String,Set<String>> , containing all copyField directives, instead of the current one at a time? That would mirror behavior of ManagedIndexSchema.addFields(), and would make it so that the schema would only need to be modified/persisted once; the above-described problem would then disappear. 3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case.
        Hide
        Steve Rowe added a comment - - edited

        Grant,

        I'm reviewing the commit you did for the first part, that added copyFields destinations to the addField(s) Java methods and the /schema/fields REST API methods.

        1. There's an issue in FieldCollectionResource.post() with persisting the schema after calling registerCopyFields() - you don't call the version of ManagedIndexSchema.addFields() you added that takes a source->dest+ copyField map param, and as a result the copyField directives won't be persisted with the other schema changes:

          IndexSchema newSchema = oldSchema.addFields(newFields);
          for (Map.Entry<String, String> entry : copyFields.entrySet()) {
            //key is the source, value is a comma separated list of targets
            String [] splits = entry.getValue().split(",");
            if (splits != null && splits.length > 0){
              for (int i = 0; i < splits.length; i++) {
                newSchema.registerCopyField(entry.getKey(), splits[i].trim());
              }
            }
          }
        

        By contrast, FieldResource.put() calls the version of the ManagedIndexSchema.addField() method you added that takes in a collection of copyField destinations, so it's fine.

        2. Ditto of my above comment #3: there is no else after the above if block to handle the case when splits is null or empty.

        3. You changed the return type of ManagedIndexSchema.addFields from ManagedIndexSchema to IndexSchema see the change here - why did you do this? I intentionally narrowed the return type when overriding this method. (There may be other instances of this kind of thing, I didn't check for others.)

        4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... -> if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back.

        Show
        Steve Rowe added a comment - - edited Grant, I'm reviewing the commit you did for the first part, that added copyFields destinations to the addField(s) Java methods and the /schema/fields REST API methods. 1. There's an issue in FieldCollectionResource.post() with persisting the schema after calling registerCopyFields() - you don't call the version of ManagedIndexSchema.addFields() you added that takes a source->dest+ copyField map param, and as a result the copyField directives won't be persisted with the other schema changes: IndexSchema newSchema = oldSchema.addFields(newFields); for (Map.Entry< String , String > entry : copyFields.entrySet()) { //key is the source, value is a comma separated list of targets String [] splits = entry.getValue().split( "," ); if (splits != null && splits.length > 0){ for ( int i = 0; i < splits.length; i++) { newSchema.registerCopyField(entry.getKey(), splits[i].trim()); } } } By contrast, FieldResource.put() calls the version of the ManagedIndexSchema.addField() method you added that takes in a collection of copyField destinations, so it's fine. 2. Ditto of my above comment #3: there is no else after the above if block to handle the case when splits is null or empty. 3. You changed the return type of ManagedIndexSchema.addFields from ManagedIndexSchema to IndexSchema see the change here - why did you do this? I intentionally narrowed the return type when overriding this method. (There may be other instances of this kind of thing, I didn't check for others.) 4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... -> if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back.
        Hide
        Grant Ingersoll added a comment -

        2. In CopyFieldsCollectionResource.post(), the loop

        Good catch! Patch shortly.

        3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case.

        But what should it do? Do you want an error?

        Show
        Grant Ingersoll added a comment - 2. In CopyFieldsCollectionResource.post(), the loop Good catch! Patch shortly. 3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case. But what should it do? Do you want an error?
        Hide
        Steve Rowe added a comment -

        3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case.

        But what should it do? Do you want an error?

        Well, if there is no exception thrown, then the method will succeed, but nothing will change, which seems wrong to me: the app should tell the user about an input problem.

        Show
        Steve Rowe added a comment - 3. There is no else after the above if block to handle the case when splits is null or empty. It's not an impossible condition - for example, "dest":",,," would trigger this case. But what should it do? Do you want an error? Well, if there is no exception thrown, then the method will succeed, but nothing will change, which seems wrong to me: the app should tell the user about an input problem.
        Hide
        Grant Ingersoll added a comment -

        4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... }} -> {{if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back

        What file is that in?

        Show
        Grant Ingersoll added a comment - 4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... }} -> {{if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back What file is that in?
        Hide
        Grant Ingersoll added a comment -

        Fixes most of Steve's issues, I believe

        Show
        Grant Ingersoll added a comment - Fixes most of Steve's issues, I believe
        Hide
        Steve Rowe added a comment -

        4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... }} -> {{if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back

        What file is that in?

        In FieldResource.java, mostly in the put() method, and ... hmm, I thought it was several files, but it was only that one.

        Show
        Steve Rowe added a comment - 4. You changed a shitload of whitespace stuff, most of which I don't care about but find annoying when evaluating patches. There is one in particular, though, that bugs me: if ( ! boolean) ... }} -> {{if (!boolean) ... - I intentionally add whitespace there to make the negation stand out, and it doesn't anymore now that you've removed the whitespace. I'd like to put those back What file is that in? In FieldResource.java, mostly in the put() method, and ... hmm, I thought it was several files, but it was only that one.
        Hide
        Steve Rowe added a comment -

        Fixes most of Steve's issues, I believe

        Aha, now I know why I thought the whitespace issue was in several files - I was lumping together code in your patch with code you had already committed. In your patch, class javadocs have whitespace rearrangements in CopyFieldCollectionResource.java and FieldCollectionResource.java, and FieldCollectionResource.java has a bunch of other whitespace changes.

        All other changes look good, except that you didn't add an exception for zero copyField destinations after splitting, and in fact you added this test, which says that such a request should succeed???:

           assertJPost("/schema/copyfields", "[{\"source\":\"fieldD\", \"dest\":\",,,\"}]", "/responseHeader/status==0");
        
        Show
        Steve Rowe added a comment - Fixes most of Steve's issues, I believe Aha, now I know why I thought the whitespace issue was in several files - I was lumping together code in your patch with code you had already committed. In your patch, class javadocs have whitespace rearrangements in CopyFieldCollectionResource.java and FieldCollectionResource.java, and FieldCollectionResource.java has a bunch of other whitespace changes. All other changes look good, except that you didn't add an exception for zero copyField destinations after splitting, and in fact you added this test, which says that such a request should succeed???: assertJPost( "/schema/copyfields" , "[{\" source\ ":\" fieldD\ ", \" dest\ ":\" ,,,\ "}]" , "/responseHeader/status==0" );
        Hide
        Grant Ingersoll added a comment -

        Fixes the empty fields issue

        Show
        Grant Ingersoll added a comment - Fixes the empty fields issue
        Hide
        Grant Ingersoll added a comment -

        More tests and error handling

        Show
        Grant Ingersoll added a comment - More tests and error handling
        Hide
        ASF subversion and git services added a comment -

        Commit 1501047 from Grant Ingersoll
        [ https://svn.apache.org/r1501047 ]

        SOLR-5010: clean up plus POST support on schema/copyfields

        Show
        ASF subversion and git services added a comment - Commit 1501047 from Grant Ingersoll [ https://svn.apache.org/r1501047 ] SOLR-5010 : clean up plus POST support on schema/copyfields
        Hide
        ASF subversion and git services added a comment -

        Commit 1501051 from Grant Ingersoll
        [ https://svn.apache.org/r1501051 ]

        SOLR-5010: merge from trunk

        Show
        ASF subversion and git services added a comment - Commit 1501051 from Grant Ingersoll [ https://svn.apache.org/r1501051 ] SOLR-5010 : merge from trunk
        Hide
        Steve Rowe added a comment -

        +1, looks good

        Show
        Steve Rowe added a comment - +1, looks good
        Hide
        ASF subversion and git services added a comment -

        Commit 1501054 from Steve Rowe
        [ https://svn.apache.org/r1501054 ]

        SOLR-5010: tweak CHANGES.txt entry to refer to full copyFields creation capabilities

        Show
        ASF subversion and git services added a comment - Commit 1501054 from Steve Rowe [ https://svn.apache.org/r1501054 ] SOLR-5010 : tweak CHANGES.txt entry to refer to full copyFields creation capabilities
        Hide
        ASF subversion and git services added a comment -

        Commit 1501056 from Steve Rowe
        [ https://svn.apache.org/r1501056 ]

        SOLR-5010: tweak CHANGES.txt entry to refer to full copyFields creation capabilities

        Show
        ASF subversion and git services added a comment - Commit 1501056 from Steve Rowe [ https://svn.apache.org/r1501056 ] SOLR-5010 : tweak CHANGES.txt entry to refer to full copyFields creation capabilities
        Hide
        Yonik Seeley added a comment -

        For a more JSONish API, perhaps we should optionally accept an array in place of a comma separated list?

        "dest" : ["myfield1", "myfield2"]
        
        Show
        Yonik Seeley added a comment - For a more JSONish API, perhaps we should optionally accept an array in place of a comma separated list? "dest" : [ "myfield1" , "myfield2" ]
        Hide
        Grant Ingersoll added a comment -

        For a more JSONish API, perhaps

        D'oh, that is a good idea. I'll correct it, but can't get to it until Thursday.

        Show
        Grant Ingersoll added a comment - For a more JSONish API, perhaps D'oh, that is a good idea. I'll correct it, but can't get to it until Thursday.
        Hide
        Yonik Seeley added a comment -

        Floks, remember when writing new tests that generate expected exceptions - you can instruct the test framework to ignore (not log) the exception explicitly with ignoreException(regex). This makes tests much more debuggable when they do fail.

        By default there is ignoreException("ignore_exception"), so sometimes the easiest way is to just make sure the exception has that string (this is what I did here: http://svn.apache.org/viewvc?view=revision&revision=r1501498

        Show
        Yonik Seeley added a comment - Floks, remember when writing new tests that generate expected exceptions - you can instruct the test framework to ignore (not log) the exception explicitly with ignoreException(regex). This makes tests much more debuggable when they do fail. By default there is ignoreException("ignore_exception"), so sometimes the easiest way is to just make sure the exception has that string (this is what I did here: http://svn.apache.org/viewvc?view=revision&revision=r1501498
        Hide
        Grant Ingersoll added a comment -

        explicitly with ignoreException(regex

        Cool

        For a more JSONish API,

        I've got a fix for this about to be committed. One of the takeaways is that a user can pass in an empty list. I changed this to not be an error condition, whereas before passing in something like ",,," was an error condition.

        Any thoughts on what is the preferred approach for a list of 1? Should I handle a plain ol' String, or require ["field"]?

        Show
        Grant Ingersoll added a comment - explicitly with ignoreException(regex Cool For a more JSONish API, I've got a fix for this about to be committed. One of the takeaways is that a user can pass in an empty list. I changed this to not be an error condition, whereas before passing in something like ",,," was an error condition. Any thoughts on what is the preferred approach for a list of 1? Should I handle a plain ol' String, or require ["field"] ?
        Hide
        ASF subversion and git services added a comment -

        Commit 1501715 from Grant Ingersoll
        [ https://svn.apache.org/r1501715 ]

        SOLR-5010: switch to lists for copy fields

        Show
        ASF subversion and git services added a comment - Commit 1501715 from Grant Ingersoll [ https://svn.apache.org/r1501715 ] SOLR-5010 : switch to lists for copy fields
        Hide
        ASF subversion and git services added a comment -

        Commit 1501718 from Grant Ingersoll
        [ https://svn.apache.org/r1501718 ]

        SOLR-5010: merge from trunk

        Show
        ASF subversion and git services added a comment - Commit 1501718 from Grant Ingersoll [ https://svn.apache.org/r1501718 ] SOLR-5010 : merge from trunk
        Hide
        ASF subversion and git services added a comment -

        Commit 1501721 from Grant Ingersoll
        [ https://svn.apache.org/r1501721 ]

        SOLR-5010: merge from branch 4_x

        Show
        ASF subversion and git services added a comment - Commit 1501721 from Grant Ingersoll [ https://svn.apache.org/r1501721 ] SOLR-5010 : merge from branch 4_x
        Hide
        Steve Rowe added a comment -

        I've got a fix for this about to be committed. One of the takeaways is that a user can pass in an empty list. I changed this to not be an error condition, whereas before passing in something like ",,," was an error condition.

        As written, an empty list will return success, but no action will be taken. Why do you treat this differently from a missing 'dest' param? Seems to me like the same problem: malformed input.

        Show
        Steve Rowe added a comment - I've got a fix for this about to be committed. One of the takeaways is that a user can pass in an empty list. I changed this to not be an error condition, whereas before passing in something like ",,," was an error condition. As written, an empty list will return success, but no action will be taken. Why do you treat this differently from a missing 'dest' param? Seems to me like the same problem: malformed input.
        Hide
        Yonik Seeley added a comment -

        Any thoughts on what is the preferred approach for a list of 1? Should I handle a plain ol' String

        +1

        Show
        Yonik Seeley added a comment - Any thoughts on what is the preferred approach for a list of 1? Should I handle a plain ol' String +1
        Hide
        Yonik Seeley added a comment -

        The current tests sometimes check for exact error messages, which gives me a little heartburn around maintainability of the tests...

        Of course, there wasn't an easy way to do anything else besides check for an exact match, so I whipped up this patch: json_regex.patch

        A special expected string of ///regex:my_regex/// will match the encountered value string with the regex.

        Thoughts?

        Show
        Yonik Seeley added a comment - The current tests sometimes check for exact error messages, which gives me a little heartburn around maintainability of the tests... Of course, there wasn't an easy way to do anything else besides check for an exact match, so I whipped up this patch: json_regex.patch A special expected string of ///regex:my_regex/// will match the encountered value string with the regex. Thoughts?
        Hide
        Grant Ingersoll added a comment -

        The current tests sometimes check for exact error messages, which gives me a little heartburn around maintainability of the tests...

        Yeah, I didn't like doing that either, but wasn't sure how else.

        As written, an empty list will return success, but no action will be taken.

        I don't see an empty list as malformed input, I guess. The client is saying don't take any action. The case of ",,," is different in that they clearly are sending in something bad, IMO.

        Handle a plain ol' String

        Will try to crank it out today.

        Show
        Grant Ingersoll added a comment - The current tests sometimes check for exact error messages, which gives me a little heartburn around maintainability of the tests... Yeah, I didn't like doing that either, but wasn't sure how else. As written, an empty list will return success, but no action will be taken. I don't see an empty list as malformed input, I guess. The client is saying don't take any action. The case of ",,," is different in that they clearly are sending in something bad, IMO. Handle a plain ol' String Will try to crank it out today.
        Hide
        ASF subversion and git services added a comment -

        Commit 1502247 from Grant Ingersoll
        [ https://svn.apache.org/r1502247 ]

        SOLR-5010: single field handling

        Show
        ASF subversion and git services added a comment - Commit 1502247 from Grant Ingersoll [ https://svn.apache.org/r1502247 ] SOLR-5010 : single field handling
        Hide
        ASF subversion and git services added a comment -

        Commit 1502250 from Grant Ingersoll
        [ https://svn.apache.org/r1502250 ]

        SOLR-5010: merge from trunk

        Show
        ASF subversion and git services added a comment - Commit 1502250 from Grant Ingersoll [ https://svn.apache.org/r1502250 ] SOLR-5010 : merge from trunk
        Hide
        ASF subversion and git services added a comment -

        Commit 1502252 from Grant Ingersoll
        [ https://svn.apache.org/r1502252 ]

        SOLR-5010: merge from branch 4_x

        Show
        ASF subversion and git services added a comment - Commit 1502252 from Grant Ingersoll [ https://svn.apache.org/r1502252 ] SOLR-5010 : merge from branch 4_x
        Hide
        Steve Rowe added a comment -

        Bulk close resolved 4.4 issues

        Show
        Steve Rowe added a comment - Bulk close resolved 4.4 issues

          People

          • Assignee:
            Grant Ingersoll
            Reporter:
            Grant Ingersoll
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development