[
https://issues.apache.org/jira/browse/SOLR-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449303#comment-13449303
]
Hoss Man commented on SOLR-3734:
--------------------------------
watching the logs while using the UI, it seems that the crux of the info all
comes from these two urls...
{noformat}
INFO: [collection1] webapp=/solr path=/admin/luke params={numTerms=0&wt=json}
status=0 QTime=10
Sep 5, 2012 4:51:45 PM org.apache.solr.core.SolrCore execute
INFO: [collection1] webapp=/solr path=/admin/luke params={wt=json&show=schema}
status=0 QTime=3
{noformat}
Ignoring for a moment that it seems absurd to me that the strings in the
"copyDests" and "copySources" arrays are the "toString" of the
SchemaField/CopyField objects, instead of just the field names: i *think* the
data in the response is correct.
It seems, if i'm understanding correctly, that the root problem is that the UI
expects all copySources returned by show=schema to be real field names that
were already by the previous numTerms=0 request - but this is not guaranteed,
nor is it abnormal to have these copyFields based on dynamicFields.
And if i'm understanding correctly, all the UI is doing with this information
is populating "Copied from" and "Copied to" lists, which then link to
"/schema-browser?field=foo" (and maybe "/schema-browser?dynamic-field=foo_*" -
but i didn't actually see any examples of that) to see details about those
fields. But the "/schema-browser?field=foo" URLs only seem to work if that
field actaully exists in the luke?numTerms=0 response -- even if they are legal
because of dynamicField.
So, for example, this address_s URL doesn't work in the UI using the example
configs on trunk if you have no data indexed, but once you index the sample
data it does start to work...
http://localhost:8983/solr/#/collection1/schema-browser?field=address_s
I think the "correct" fixes would be...
* the UI should not freak out if a copySources or copyDest refers to a field or
dynamic field pattern it doesn't know about. it should list it in the display
as usual and provide the appropriate ?field=foo or ?field=foo_* link (depending
on wether the copySource contains a wildcard.
* if someone clicks on one of those links, and there is no field data available
about a field (because it isn't explicitly declared, nor does it exist in the
index, so it's not returned by the luke?numTerms=0 request) then the UI should
display a simple warning "Field not found in index, no details available" or
something like that.
We can probably look into improving that second case in the future (so even if
it's not in the index, and wasn't returned by the luke?numTerms-0 request, the
UI should be able to ask luke for info about a field by name, and have luke
response back with "not currently in the index, but it is a legal field name
because of dynamicField foo_*, and heres' the fieldType and field flags")
> Forever loop in schema browser
> ------------------------------
>
> Key: SOLR-3734
> URL: https://issues.apache.org/jira/browse/SOLR-3734
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
> Reporter: Lance Norskog
> Attachments: SOLR-3734.patch,
> SOLR-3734_schema_browser_blocks_solr_conf_dir.zip
>
>
> When I start Solr with the attached conf directory, and hit the Schema
> Browser, the loading circle spins permanently.
> I don't know if the problem is in the UI or in Solr. The UI does not display
> the Ajax solr calls, and I don't have a debugging proxy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
