Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 4.0-ALPHA
-
Fix Version/s: None
-
Component/s: search
-
Labels:None
-
Environment:
apache-solr-4.0-2012-04-24_08-27-47
Description
When specifying a field name that starts with a digit (or digits) in the "fl" parameter solr returns both the field name and field value as the those digits. For example, using nightly build "apache-solr-4.0-2012-04-24_08-27-47" I run:
java -jar start.jar
and
java -jar post.jar solr.xml monitor.xml
If I then add a field to the field list that starts with a digit ( localhost:8983/solr/select?q=:&fl=24 ) the results look like:
...
<doc>
<long name="24">24</long>
</doc>
...
if I try fl=24_7 it looks like everything after the underscore is truncated
...
<doc>
<long name="24">24</long>
</doc>
...
and if I try fl=3test it looks like everything after the last digit is truncated
...
<doc>
<long name="3">3</long>
</doc>
...
If I have an actual value for that field (say I've indexed 24_7 to be "true" ) I get back that value as well as the behavior above.
...
<doc>
<bool name="24_7">true</bool>
<long name="24">24</long>
</doc>
...
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
See the comment in the schema.xml:
<!-- 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.
-->
OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. Just because it's documented does not excuse poor decisions.
We really should start enforcing the field names we allow IMO.
an unnecessary change that serves no purpose.
What exactly is the change you are referring to?
I guess this is a side effect coming from SOLR-2444. Solr already had similar problems (SOLR-2719: hyphen within the field name didn't work anymore). Some kind of validation would help (SOLR-3207) but it's not trivial to do since there are dynamic fields too; I think Solr should guarantee that allowed field names always work, or at least make clearer what restrictions there are.
This does NOT happen on 3.6, but DOES happen on trunk.