Solr
  1. Solr
  2. SOLR-1071

spellcheck.extendedResults returns an invalid JSON response when count > 1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: spellchecker
    • Labels:
      None

      Description

      When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the suggestions are returned in the following format:

      "suggestions":[
      "amsterdm",{
      "numFound":5,
      "startOffset":0,
      "endOffset":8,
      "origFreq":0,
      "suggestion":

      { "frequency":8498, "word":"amsterdam"}

      ,
      "suggestion":

      { "frequency":1, "word":"amsterd"}

      ,
      "suggestion":

      { "frequency":8, "word":"amsterdams"}

      ,
      "suggestion":

      { "frequency":1, "word":"amstedam"}

      ,
      "suggestion":{
      "frequency":22,
      "word":"amsterdamse"}},
      "beak",{
      "numFound":5,
      "startOffset":9,
      "endOffset":13,
      "origFreq":0,
      "suggestion":

      { "frequency":379, "word":"beek"}

      ,
      "suggestion":

      { "frequency":26, "word":"beau"}

      ,
      "suggestion":

      { "frequency":26, "word":"baak"}

      ,
      "suggestion":

      { "frequency":15, "word":"teak"}

      ,
      "suggestion":{
      "frequency":11,
      "word":"beuk"}},
      "correctlySpelled",false,
      "collation","amsterdam beek"]}}

      This is an invalid json as each term is associated with a JSON object which holds multiple "suggestion" attributes. When working with a JSON library only the last "suggestion" attribute is picked up.

      1. SOLR-1071.patch
        14 kB
        Yonik Seeley
      2. SpellCheckComponent_fix.patch
        0.8 kB
        Uri Boness
      3. SpellCheckComponent_new_structure_incl_test.patch
        8 kB
        Uri Boness
      4. SpellCheckComponent_new_structure.patch
        2 kB
        Uri Boness

        Activity

        Hide
        Grant Ingersoll added a comment -

        I don't know much about JSON, but it is my understanding that it is all generated from the NamedList, so I'm not sure what the solution would be.

        Show
        Grant Ingersoll added a comment - I don't know much about JSON, but it is my understanding that it is all generated from the NamedList, so I'm not sure what the solution would be.
        Hide
        Donovan Jimenez added a comment -

        the JSON response writer has a specific parameter for this case: json.nl

        It allows the the user to specify how they want named lists (which don't necessarily have unique keys suited to a JSON object map) to be treated. The values are listed in the wiki documentation:

        http://wiki.apache.org/solr/SolJSON

        I believe it affects the treatment of all named lists in the response, so if you're using facets or the like, they'd also be affected.

        Show
        Donovan Jimenez added a comment - the JSON response writer has a specific parameter for this case: json.nl It allows the the user to specify how they want named lists (which don't necessarily have unique keys suited to a JSON object map) to be treated. The values are listed in the wiki documentation: http://wiki.apache.org/solr/SolJSON I believe it affects the treatment of all named lists in the response, so if you're using facets or the like, they'd also be affected.
        Hide
        Grant Ingersoll added a comment -

        Uri, does that solve your problem?

        Show
        Grant Ingersoll added a comment - Uri, does that solve your problem?
        Hide
        Uri Boness added a comment -

        OK, so I checked it out and no, setting the json.nl parameter doesn't help in this case. I looked it up and the problem lays in the fact that the suggestions data structure is SimpleOrderedMap. SimpleOrderedMap structure are always renderer by the JsonResponseWriter as a map and are not influenced by the json.nl parameter. There are two possible solutions here as I see it:

        1. A simple fix that would just replace the current SimpleOrderedMap with an ordinary NamedList (see SpecllCheckComponent_fix.patch)
        Advantages: More backward compatible
        Disadvantages: you still need to use the json.nl parameter in order to get it to work (and the this parameter influences the complete response structure, not just the spellcheck output)

        2. A small change to the response data structure that will put all the suggestion items as an array value of one field named "suggestionItems" (see SpellCheckComponent_new_structure.patch)
        Advantages: A proper and intuitive structure for the response
        Disadvantages: probably less backward compatible as the first solution

        (NOTE: patches applied on the trunk version)

        Show
        Uri Boness added a comment - OK, so I checked it out and no, setting the json.nl parameter doesn't help in this case. I looked it up and the problem lays in the fact that the suggestions data structure is SimpleOrderedMap. SimpleOrderedMap structure are always renderer by the JsonResponseWriter as a map and are not influenced by the json.nl parameter. There are two possible solutions here as I see it: 1. A simple fix that would just replace the current SimpleOrderedMap with an ordinary NamedList (see SpecllCheckComponent_fix.patch) Advantages: More backward compatible Disadvantages: you still need to use the json.nl parameter in order to get it to work (and the this parameter influences the complete response structure, not just the spellcheck output) 2. A small change to the response data structure that will put all the suggestion items as an array value of one field named "suggestionItems" (see SpellCheckComponent_new_structure.patch) Advantages: A proper and intuitive structure for the response Disadvantages: probably less backward compatible as the first solution (NOTE: patches applied on the trunk version)
        Hide
        Yonik Seeley added a comment -

        2. A small change to the response data structure that will put all the suggestion items as an array value of one field named "suggestionItems"

        +1... how about "suggestions" for the tag though.

        Show
        Yonik Seeley added a comment - 2. A small change to the response data structure that will put all the suggestion items as an array value of one field named "suggestionItems" +1... how about "suggestions" for the tag though.
        Hide
        Uri Boness added a comment -

        At first I tagged it "suggestions" but then I thought it might be confusing having two such tags on different levels

        Show
        Uri Boness added a comment - At first I tagged it "suggestions" but then I thought it might be confusing having two such tags on different levels
        Hide
        Donovan Jimenez added a comment -

        Some other response writers, like Serialized PHP for example, always output an object or keyed array for named lists. Do they need to implement similar parameters as the JSON writer? Or, like the direction you seem to be going here, should all response structures avoid the use of named lists with repeating element names?

        This seems, at least to me, like a more general issue of convention and guidelines in the search components.

        Show
        Donovan Jimenez added a comment - Some other response writers, like Serialized PHP for example, always output an object or keyed array for named lists. Do they need to implement similar parameters as the JSON writer? Or, like the direction you seem to be going here, should all response structures avoid the use of named lists with repeating element names? This seems, at least to me, like a more general issue of convention and guidelines in the search components.
        Hide
        Yonik Seeley added a comment - - edited

        At first I tagged it "suggestions" but then I thought it might be confusing having two such tags on different levels

        good point - I hadn't noticed it was the same as the top level tag.
        We could use a different word altogether... say "words", "terms", "replacements", "alternatives","corrections"?

        Show
        Yonik Seeley added a comment - - edited At first I tagged it "suggestions" but then I thought it might be confusing having two such tags on different levels good point - I hadn't noticed it was the same as the top level tag. We could use a different word altogether... say "words", "terms", "replacements", "alternatives","corrections"?
        Hide
        Uri Boness added a comment - - edited

        I think "alternatives" and "corrections" are best candidate semantically speaking. Personally, I like "alternatives" the most but "corrections" is good as well.

        Show
        Uri Boness added a comment - - edited I think "alternatives" and "corrections" are best candidate semantically speaking. Personally, I like "alternatives" the most but "corrections" is good as well.
        Hide
        Uri Boness added a comment -

        Changed "items" to "alternatives" and updated the SpellCheckComponentTest class accordingly.

        Show
        Uri Boness added a comment - Changed "items" to "alternatives" and updated the SpellCheckComponentTest class accordingly.
        Hide
        Uri Boness added a comment -

        One more thing to consider: now this component is a bit inconsistent with its response format. When extendedResults is used, the suggestions are put in an array called "alternatives", while when it's not used the suggestions are put in an array called "suggestion". I think it will be wise to consider changing the later to "alternatives" as well, but of course it will break backward compatibility and as this component is probably widely used it's a risk. Another option is at least temporary for 1.4 release add support for another parameter (something like, spellcheck.version=1.3) that will then signal the component to render the response in the 1.3 format - a bit ugly, but it will at least solve the compatibility issues.

        Show
        Uri Boness added a comment - One more thing to consider: now this component is a bit inconsistent with its response format. When extendedResults is used, the suggestions are put in an array called "alternatives", while when it's not used the suggestions are put in an array called "suggestion". I think it will be wise to consider changing the later to "alternatives" as well, but of course it will break backward compatibility and as this component is probably widely used it's a risk. Another option is at least temporary for 1.4 release add support for another parameter (something like, spellcheck.version=1.3) that will then signal the component to render the response in the 1.3 format - a bit ugly, but it will at least solve the compatibility issues.
        Hide
        Grant Ingersoll added a comment -

        When extendedResults is used, the suggestions are put in an array called "alternatives", while when it's not used the suggestions are put in an array called "suggestion".

        I debated the two different structures for a while and ultimately decided that people would have to deal with it no matter what. My suspicion was that people either use extendedResults or not and that they don't mix them, but perhaps I was wrong. Even if they do mix them, they still need code for recognizing when there is a difference (unless they are just spitting back out the raw, which means it doesn't matter anyway), so I don't know if it matters either way. Since this is out in the wild already, I think we should just fix the bug.

        Show
        Grant Ingersoll added a comment - When extendedResults is used, the suggestions are put in an array called "alternatives", while when it's not used the suggestions are put in an array called "suggestion". I debated the two different structures for a while and ultimately decided that people would have to deal with it no matter what. My suspicion was that people either use extendedResults or not and that they don't mix them, but perhaps I was wrong. Even if they do mix them, they still need code for recognizing when there is a difference (unless they are just spitting back out the raw, which means it doesn't matter anyway), so I don't know if it matters either way. Since this is out in the wild already, I think we should just fix the bug.
        Hide
        Grant Ingersoll added a comment -

        One thought, though:

        Why isn't this a JSONResponseWriter bug? It seems to me that the code is using valid Solr data structures and that the problem lies in the fact that the JSONRW is not creating valid JSON output. Say we fix this here in the SCC, it doesn't stop anyone from doing it anywhere else, which will just lead to more bugs later.

        Show
        Grant Ingersoll added a comment - One thought, though: Why isn't this a JSONResponseWriter bug? It seems to me that the code is using valid Solr data structures and that the problem lies in the fact that the JSONRW is not creating valid JSON output. Say we fix this here in the SCC, it doesn't stop anyone from doing it anywhere else, which will just lead to more bugs later.
        Hide
        Uri Boness added a comment -

        I debated the two different structures for a while and ultimately decided that people would have to deal with it no matter what. My suspicion was that people either use extendedResults or not and that they don't mix them, but perhaps I was wrong. Even if they do mix them, they still need code for recognizing when there is a difference (unless they are just spitting back out the raw, which means it doesn't matter anyway), so I don't know if it matters either way. Since this is out in the wild already, I think we should just fix the bug.

        I guess you're right - the users will have to handle the differences between the results anyway

        Show
        Uri Boness added a comment - I debated the two different structures for a while and ultimately decided that people would have to deal with it no matter what. My suspicion was that people either use extendedResults or not and that they don't mix them, but perhaps I was wrong. Even if they do mix them, they still need code for recognizing when there is a difference (unless they are just spitting back out the raw, which means it doesn't matter anyway), so I don't know if it matters either way. Since this is out in the wild already, I think we should just fix the bug. I guess you're right - the users will have to handle the differences between the results anyway
        Hide
        Uri Boness added a comment -

        I'm not sure it's a bug in the JSONRW, it seems to me that it was intentionally implemented to behave in this manner. It is confusing though, and indeed when developing components one has to keep in mind the consequences of using a SimpleOrderedMap vs. a simple NamedList.

        I think there are several ways to tackle this:

        1. Do nothing. In which case people should always know the consequences of using a SimpleOrderedMap vs. a simple NamedList.
        Advantages: you probably don't break existing functionality. No code changes need to take place.
        Disadvantages: (as you mentioned) more error prone - easier to introduce such bugs when writing new components. People need to know the best practices which are not enforced.

        2. In the SimpleOrderedMap, keep track of duplicate keys. If a SimpleOrderedMap hold duplicate keys then it should not be rendered as a JSON object, but more like a normal NamedList
        Advantages: you probably break nothing.. if components already use duplicate keys in a SimpleOrderedMap then most probably they've introduced this same bug.
        Disadvantage: Inconsistent in the sense that in different occasions a SimpleOrderedMap will be rendered differently. If duplicate keys are added, then there's no added value in choosing SimpleOrderedMap over a normal NamedList. Which brings me to the last option

        3. Make sure that SimpleOrderedMap does not accept duplicates. Either by enforcing it (e.g. by throwing an exception) or just by overriding the values.
        Advantages: Gives the SimpleOrderedMap a true meaning and a reason to exist. With this in place, it will be clear when and how it can be used. No changes need to be applied to the JSONRW.
        Disadvantages: Existing functionality might break, yet again... if duplicate keys are already used than this bug is introduced anyway. According to the Javadoc, the SimpleOrderedMap implementation intentionality doesn't prevent duplicate keys... so there must be a reason for that.

        Personally, I'm for option 3. The current implementation of SimpleOrderedMap doesn't seem to add any functionality to the NamedList class, so it seems to me this class was created just as a hint for the response writers to render it differently. The name "SimpleOrderedMap" also suggest a "Map-like" functionality which doesn't support duplicate keys. But again, I'm not sure about the original reasons for not preventing duplicate keys in the first place, so there might be something I'm missing here.

        Show
        Uri Boness added a comment - I'm not sure it's a bug in the JSONRW, it seems to me that it was intentionally implemented to behave in this manner. It is confusing though, and indeed when developing components one has to keep in mind the consequences of using a SimpleOrderedMap vs. a simple NamedList . I think there are several ways to tackle this: 1. Do nothing. In which case people should always know the consequences of using a SimpleOrderedMap vs. a simple NamedList. Advantages: you probably don't break existing functionality. No code changes need to take place. Disadvantages: (as you mentioned) more error prone - easier to introduce such bugs when writing new components. People need to know the best practices which are not enforced. 2. In the SimpleOrderedMap , keep track of duplicate keys. If a SimpleOrderedMap hold duplicate keys then it should not be rendered as a JSON object, but more like a normal NamedList Advantages: you probably break nothing.. if components already use duplicate keys in a SimpleOrderedMap then most probably they've introduced this same bug. Disadvantage: Inconsistent in the sense that in different occasions a SimpleOrderedMap will be rendered differently. If duplicate keys are added, then there's no added value in choosing SimpleOrderedMap over a normal NamedList . Which brings me to the last option 3. Make sure that SimpleOrderedMap does not accept duplicates. Either by enforcing it (e.g. by throwing an exception) or just by overriding the values. Advantages: Gives the SimpleOrderedMap a true meaning and a reason to exist. With this in place, it will be clear when and how it can be used. No changes need to be applied to the JSONRW. Disadvantages: Existing functionality might break, yet again... if duplicate keys are already used than this bug is introduced anyway. According to the Javadoc, the SimpleOrderedMap implementation intentionality doesn't prevent duplicate keys... so there must be a reason for that. Personally, I'm for option 3. The current implementation of SimpleOrderedMap doesn't seem to add any functionality to the NamedList class, so it seems to me this class was created just as a hint for the response writers to render it differently. The name "SimpleOrderedMap" also suggest a "Map-like" functionality which doesn't support duplicate keys. But again, I'm not sure about the original reasons for not preventing duplicate keys in the first place, so there might be something I'm missing here.
        Hide
        Yonik Seeley added a comment -

        Why isn't this a JSONResponseWriter bug?

        JSON does not require unique keys. It's certainly a good idea though.

        Donovan had it right:

        This seems, at least to me, like a more general issue of convention and guidelines in the search components.

        It's a bad idea to repeat keys... this isn't XML. When access-by-key is more important, use SimpleOrderedMap... when position must be maintained, use NamedList. In both cases, we should strive not to repeat keys.

        Here is what the current output is for non-extendedResults:

         <lst name="suggestions">
          <lst name="hell">
        	<int name="numFound">2</int>
        	<int name="startOffset">0</int>
        	<int name="endOffset">4</int>
        	<arr name="suggestion">
        	 <str>dell</str>
        	 <str>all</str>
        	</arr>
          </lst>
         </lst>
        

        The logical extension for extended results would be to simply replace each string in the array with a map.

          <lst name="hell">
        	<int name="numFound">2</int>
        	<int name="startOffset">0</int>
        	<int name="endOffset">4</int>
        	<int name="origFreq">0</int>
                <arr name="suggestion">
                   <lst>
        		 <int name="frequency">1</int>
          	         <str name="word">dell</str>
                   </lst>
                   <lst>
        	         <int name="frequency">1</int>
        	         <str name="word">all</str>
                   </lst>
        	</arr>
          </lst>
        

        If extended results only ever added frequency, we could further simplify to have the suggest be the key and the freq be the val, but I don't know that we wouldn't want to add more metadata in the future.

        Show
        Yonik Seeley added a comment - Why isn't this a JSONResponseWriter bug? JSON does not require unique keys. It's certainly a good idea though. Donovan had it right: This seems, at least to me, like a more general issue of convention and guidelines in the search components. It's a bad idea to repeat keys... this isn't XML. When access-by-key is more important, use SimpleOrderedMap... when position must be maintained, use NamedList. In both cases, we should strive not to repeat keys. Here is what the current output is for non-extendedResults: <lst name= "suggestions" > <lst name= "hell" > < int name= "numFound" >2</ int > < int name= "startOffset" >0</ int > < int name= "endOffset" >4</ int > <arr name= "suggestion" > <str>dell</str> <str>all</str> </arr> </lst> </lst> The logical extension for extended results would be to simply replace each string in the array with a map. <lst name= "hell" > < int name= "numFound" >2</ int > < int name= "startOffset" >0</ int > < int name= "endOffset" >4</ int > < int name= "origFreq" >0</ int > <arr name= "suggestion" > <lst> < int name= "frequency" >1</ int > <str name= "word" >dell</str> </lst> <lst> < int name= "frequency" >1</ int > <str name= "word" >all</str> </lst> </arr> </lst> If extended results only ever added frequency, we could further simplify to have the suggest be the key and the freq be the val, but I don't know that we wouldn't want to add more metadata in the future.
        Hide
        Stephen Day added a comment -

        Why did this ever change to begin with? From the wiki, there is a clear definition of how it originally worked, that was compatible with the JSON Writer:

        http://wiki.apache.org/solr/SpellCheckComponent

        The current format is obnoxiously verbose, even for XML.

        Show
        Stephen Day added a comment - Why did this ever change to begin with? From the wiki, there is a clear definition of how it originally worked, that was compatible with the JSON Writer: http://wiki.apache.org/solr/SpellCheckComponent The current format is obnoxiously verbose, even for XML.
        Hide
        Uri Boness added a comment -

        Because there are issues with the current format is json (and perhaps also in other formats)... see comments above

        Show
        Uri Boness added a comment - Because there are issues with the current format is json (and perhaps also in other formats)... see comments above
        Hide
        Yonik Seeley added a comment - - edited

        I'm moving forward with the most straightforward fix... the string becomes a map for extended results. So
        <str>dell</str> in non extended results becomes the following in extended results:
        <lst> <str name="word">dell</str> <int name="freq">1</int> </lst>

        So voice your objections now

        Actually, the code to do the change is already done... the hard part is the tests... and there seems to be no unit tests for the SolrJ part that actually test the Suggestion class.

        Show
        Yonik Seeley added a comment - - edited I'm moving forward with the most straightforward fix... the string becomes a map for extended results. So <str>dell</str> in non extended results becomes the following in extended results: <lst> <str name="word">dell</str> <int name="freq">1</int> </lst> So voice your objections now Actually, the code to do the change is already done... the hard part is the tests... and there seems to be no unit tests for the SolrJ part that actually test the Suggestion class.
        Hide
        Yonik Seeley added a comment -

        Attaching patch.

        Here is some example JSON output:

         "spellcheck":{
          "suggestions":[
        	"hell",{
        	 "numFound":2,
        	 "startOffset":0,
        	 "endOffset":4,
        	 "origFreq":0,
        	 "suggestion":[{
        		"word":"dell",
        		"freq":4},
        	  {
        		"word":"all",
        		"freq":4}]},
        	"correctlySpelled",false]}}
        
        Show
        Yonik Seeley added a comment - Attaching patch. Here is some example JSON output: "spellcheck" :{ "suggestions" :[ "hell" ,{ "numFound" :2, "startOffset" :0, "endOffset" :4, "origFreq" :0, "suggestion" :[{ "word" : "dell" , "freq" :4}, { "word" : "all" , "freq" :4}]}, "correctlySpelled" , false ]}}
        Hide
        Yonik Seeley added a comment -

        I haven't changed the SolrJ SpellCheckResponse class, but it does look like the naming could be improved.

        Example:
        response.getSuggestions().get(0).getSuggestions().get(0);

        Show
        Yonik Seeley added a comment - I haven't changed the SolrJ SpellCheckResponse class, but it does look like the naming could be improved. Example: response.getSuggestions().get(0).getSuggestions().get(0);
        Hide
        Uri Boness added a comment -

        Looks good!

        As for the naming, I really like your suggestion (in one of the comments above) to replace "suggestion" with "alternatives". So the client code can look something like:

        response.getSuggestions().get("hell").getAlternatives().get(0);
        

        One more thing - I think it will be more intuitive to use a SimpleOrderedMap instead of a NamedList for the "suggestions" node. for the xml response it won't make much difference I guess, but for the json one it will be more intuitive and easier to work with. So to take your example above, you'd get something like:

        "spellcheck": {
            "suggestions": {
                "hell":{
                    "numFound":2,
                    "startOffset":0,
                    "endOffset":4,
                    "origFreq":0,
                    "alternatives":[
                        {
                            "word":"dell",
                            "freq":4
                        },
                        {
                            "word":"all",
                            "freq":4
                        }
                    ]
                },
                "correctlySpelled":false}}}
        
        Show
        Uri Boness added a comment - Looks good! As for the naming, I really like your suggestion (in one of the comments above) to replace "suggestion" with "alternatives". So the client code can look something like: response.getSuggestions().get( "hell" ).getAlternatives().get(0); One more thing - I think it will be more intuitive to use a SimpleOrderedMap instead of a NamedList for the "suggestions" node. for the xml response it won't make much difference I guess, but for the json one it will be more intuitive and easier to work with. So to take your example above, you'd get something like: "spellcheck" : { "suggestions" : { "hell" :{ "numFound" :2, "startOffset" :0, "endOffset" :4, "origFreq" :0, "alternatives" :[ { "word" : "dell" , "freq" :4 }, { "word" : "all" , "freq" :4 } ] }, "correctlySpelled" : false }}}
        Hide
        Yonik Seeley added a comment -

        Thanks for the review Uri!

        One more thing - I think it will be more intuitive to use a SimpleOrderedMap instead of a NamedList for the "suggestions" node.

        It already does... it's just the client code that checks for NamedList (the parent of SimpleOrderedMap)

        Show
        Yonik Seeley added a comment - Thanks for the review Uri! One more thing - I think it will be more intuitive to use a SimpleOrderedMap instead of a NamedList for the "suggestions" node. It already does... it's just the client code that checks for NamedList (the parent of SimpleOrderedMap)
        Hide
        Uri Boness added a comment -

        It already does... it's just the client code that checks for NamedList (the parent of SimpleOrderedMap)

        No... sorry, I mean the top most "suggestions" node. line 182 in the patched class.

        Show
        Uri Boness added a comment - It already does... it's just the client code that checks for NamedList (the parent of SimpleOrderedMap) No... sorry, I mean the top most "suggestions" node. line 182 in the patched class.
        Hide
        Yonik Seeley added a comment -

        I mean the top most "suggestions" node.

        Oh I see - I wasn't sure about that one... I guess it depends on how important order is in the top-level suggestions list? It would break back compat for the non-extended results too (for JSON and friends).

        Show
        Yonik Seeley added a comment - I mean the top most "suggestions" node. Oh I see - I wasn't sure about that one... I guess it depends on how important order is in the top-level suggestions list? It would break back compat for the non-extended results too (for JSON and friends).
        Hide
        Uri Boness added a comment -

        I guess it depends on how important order is in the top-level suggestions list?

        I guess the order is not that important, it's just that using a SimpleOrderedMap will output a more intuitive JSON output to work with IMO.

        It would break back compat for the non-extended results too (for JSON and friends).

        True... I didn't think about that one. hmm... well... I guess you can keep it as is then. I mean, it's not like you cannot work with the current format after all

        Show
        Uri Boness added a comment - I guess it depends on how important order is in the top-level suggestions list? I guess the order is not that important, it's just that using a SimpleOrderedMap will output a more intuitive JSON output to work with IMO. It would break back compat for the non-extended results too (for JSON and friends). True... I didn't think about that one. hmm... well... I guess you can keep it as is then. I mean, it's not like you cannot work with the current format after all
        Hide
        Yonik Seeley added a comment -

        Committed! The Solr release schedule is tight enough, I'll update the wiki docs during the Solr code freeze (unless someone beats me to it).

        Show
        Yonik Seeley added a comment - Committed! The Solr release schedule is tight enough, I'll update the wiki docs during the Solr code freeze (unless someone beats me to it).
        Hide
        Uri Boness added a comment -

        cool! thanks for the effort Yonik. I've updated the wiki so you can focus on the release

        Show
        Uri Boness added a comment - cool! thanks for the effort Yonik. I've updated the wiki so you can focus on the release
        Hide
        Grant Ingersoll added a comment -

        Bulk close Solr 1.4 issues

        Show
        Grant Ingersoll added a comment - Bulk close Solr 1.4 issues

          People

          • Assignee:
            Yonik Seeley
            Reporter:
            Uri Boness
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development