[
https://issues.apache.org/jira/browse/SOLR-9205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Woodward updated SOLR-9205:
--------------------------------
Attachment: SOLR-9205.patch
Slightly amended patch - I decided not to deprecate the old method, as it's
still useful, and I folded the test into an existing LukeResponse test. Will
commit shortly.
> Parse schema in LukeResponse
> ----------------------------
>
> Key: SOLR-9205
> URL: https://issues.apache.org/jira/browse/SOLR-9205
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Fengtan
> Priority: Minor
> Attachments: SOLR-9205.patch, SOLR-9205.patch, SOLR-9205.patch
>
>
> LukeRequestHandler (/admin/luke) lists schema flags using two fields named
> "schema" and "flags".
> For instance on my local machine
> http://localhost:8983/solr/collection1/admin/luke returns something like this:
> {code:xml}
> <lst name="id">
> <str name="type">string</str>
> <str name="schema">I-S-----OF-----l</str>
> </lst>
> {code}
> And http://localhost:8983/solr/collection1/admin/luke?show=schema returns
> something like this:
> {code:xml}
> <lst name="id">
> <str name="type">string</str>
> <str name="flags">I-S-----OF-----l</str>
> </lst>
> {code}
> However, when processing a LukeRequest in SolrJ, only the "flags" field is
> parsed into a Set of FieldFlag objects. The "schema" field is left as a
> String, and as a result is hard to process by client applications who do not
> know how to parse "I-S-----OF-----l".
> Here is an example that illustrates the problem:
> {code}
> public class MyClass {
> public static void main(String[] args) throws Exception {
> SolrClient client = new
> HttpSolrClient("http://localhost:8983/solr/collection1";);
> LukeRequest request = new LukeRequest();
> LukeResponse response = request.process(client);
> for (LukeResponse.FieldInfo field:response.getFieldInfo().values()) {
> System.out.println(field.getSchema());
> // field.getSchema() returns "I-S-----OF------" (i.e. a String) which
> is not much meaningful for SolrJ applications
> // Ideally field.getSchema() should return something like "[INDEXED,
> STORED, OMIT_NORMS, OMIT_TF]" (i.e. a EnumSet<FieldFlag>) which is meaningful
> for SolrJ applications
> }
> }
> }
> {code}
> It is probably fine to parse both fields the same way in SolrJ since
> LukeRequestHandler populates them [the same
> way|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/LukeRequestHandler.java#L288].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
