[ 
https://issues.apache.org/jira/browse/SOLR-10494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-10494:
----------------------------
    Attachment: SOLR-10494.patch



bq. ...I'm pretty sure the root problem here is that with the change to default 
to indent=true, really deep XML docs are including more newlines in places they 
weren't before, and that's causing some bugs in the SOlrJ XMLResponseParse ...

The scope of the bug was much more narrow then i realized: it *only* affected 
nested child docs when {{indent=true}} (newlines had nothing to do with it) -- 
fixed now in SOLR-11136.

----

bq. I tried to debug theTestHierarchicalDocBuilder.testThreeLevelHierarchy test 
failure, and I see that the test data is different but that may be the 
intention, to randomize the hierarchy.

that failure is actually really simple: the xpath is badly written.  it's using 
syntax like {{/arr\[@name='id' and .='"+parentId1+"']}} which only works if 
*all* of the accumlated text data inside the {{<arr>}} equal {{parentId}} after 
they've been concatenated -- but when {{indent=true}} there are additional 
(whitespace) text data nodes in the DOM before and after the {{<str>...</str>}}.

In the attached path i simplified & tightened up these xpaths to be explicit 
about looking for the {{<str>...</str>}} content.

(NOTE: still haven't actaully reviewed the patch, just focused on getting the 
tests to pass)


> Switch Solr's Default Response Type from XML to JSON
> ----------------------------------------------------
>
>                 Key: SOLR-10494
>                 URL: https://issues.apache.org/jira/browse/SOLR-10494
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Response Writers
>    Affects Versions: 7.0
>            Reporter: Trey Grainger
>            Priority: Blocker
>             Fix For: 7.0
>
>         Attachments: SOLR-10494, SOLR-10494, SOLR-10494.branch_7x.patch, 
> SOLR-10494.patch, SOLR-10494.patch, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to