[
https://issues.apache.org/jira/browse/SOLR-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166397#comment-15166397
]
Jason Gerlowski edited comment on SOLR-8110 at 2/25/16 12:18 AM:
-----------------------------------------------------------------
Noticed something a little odd (to me) while doing some manual tests on the
patch I pushed up last night....
With the added checks in the patch, core creation will fail if the core-create
request references a configset containing an invalid field declaration. Solr
returns BAD_REQUEST (400), and a message containing: {{Unable to create core
[gettingstarted_shard1_replica2] Caused by: Dynamic field name '*_i$#' is
invalid. Dynamic field names can only containalphanumerics, underscores,
periods, and prefix/suffix asterisks.}} All looks good.
When I test this out by creating a collection though, the result is more mixed.
Solr returns an OK (200) status code. The message body though, contains a
similar error message to the one above:
{code}
[~/c/s/l/solr] $ curl -i -l -k -X GET
"http://localhost:8983/solr/admin/collections?action=CREATE&name=asdf&collection.configName=gettingstarted&numShards=1";
HTTP/1.1 200 OK
...
<response>
<lst name="responseHeader"><int name="status">0</int><int
name="QTime">2841</int></lst><lst name="failure"><str
name="127.0.1.1:7574_solr">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
from server at http://127.0.1.1:7574/solr: Error CREATEing SolrCore
'asdf_shard1_replica1': Unable to create core [asdf_shard1_replica1] Caused by:
Dynamic field name '*_i$#' is invalid. Dynamic field names can only
containalphanumerics, underscores, periods, and prefix/suffix
asterisks.</str></lst>
</response>
{code}
Cluster-status and core-status requests confirm that the cores failed to
initialize correctly, and were never fully created.
My interpretation of this is that the collection-create commands fires off the
core-create requests, but doesn't correctly interpret their success/failure.
Is this expected/correct behavior, or is this a bug in the Collections API?
Seems like a bug to me, but I'm not super familiar with the expected behavior
of the Collections API, so just thought I'd mention it here before creating a
JIRA out of it.
was (Author: gerlowskija):
Noticed something a little odd (to me) while doing some manual tests on the
patch I pushed up last night....
With the added checks in the patch, core creation will fail if the core-create
request references a configset containing an invalid field declaration. Solr
returns BAD_REQUEST (400), and a message containing: {{Unable to create core
[gettingstarted_shard1_replica2] Caused by: Dynamic field name '*_i$#' is
invalid. Dynamic field names can only containalphanumerics, underscores,
periods, and prefix/suffix asterisks.}} All looks good.
When I test this out by creating a collection though, the result is more mixed.
Solr returns an OK (200) status code. The message body though, contains a
similar error message to the one above:
{code}
[~/c/s/l/solr] $ curl -i -l -k -X GET
"http://localhost:8983/solr/admin/collections?action=CREATE&name=asdf&collection.configName=gettingstarted&numShards=1";
HTTP/1.1 200 OK
...
<response>
<lst name="responseHeader"><int name="status">0</int><int
name="QTime">2841</int></lst><lst name="failure"><str
name="127.0.1.1:7574_solr">org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
from server at http://127.0.1.1:7574/solr: Error CREATEing SolrCore
'asdf_shard1_replica1': Unable to create core [asdf_shard1_replica1] Caused by:
Dynamic field name '*_i$#' is invalid. Dynamic field names can only
containalphanumerics, underscores, periods, and prefix/suffix
asterisks.</str></lst>
</response>
{code}
Cluster-status and core-status requests confirm that the cores failed to
initialize correctly, and were never fully created.
My interpretation of this is that the collection-create commands fires off the
core-create requests, but doesn't correctly interpret their success/failure.
Is this expected/correct behavior, or is this a bug in the Collections API?
Seems like a bug to me, but I'm not super familiar with the expected behavior
of the Collections API, so just thought I'd mention it here before creating a
JIRA out of it.
> Start enforcing field naming recomendations in next X.0 release?
> ----------------------------------------------------------------
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Attachments: SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation"
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only
> and not start with a digit. This is not currently strictly enforced, but
> other field names will not have first class support from all components and
> back compatibility is not guaranteed. ...
> I'm opening this issue to track discussion about if/how we should start
> enforcing this as a rule instead (instead of just a "recommendation") in our
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with
> lists of field and produce strange errors when the huerstic fails (example:
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the
> recommended conventions and then only later encountering a situation where
> their field names are not supported by some feature and get frustrated
> because they have to change their schema, reindex, update index/query client
> expectations, etc...
--
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
