Nathan Neulinger created SOLR-6255: -------------------------------------- Summary: Misleading error message when usable questionable update syntax Key: SOLR-6255 URL: https://issues.apache.org/jira/browse/SOLR-6255 Project: Solr Issue Type: Bug Components: query parsers Environment: 4.8.0, Linux x86_64, jdk 1.7.55, 2 x Node, External ZK, SolrCloud Reporter: Nathan Neulinger
When issuing an update with the following questionable JSON as input, it returns (for the attached schema) an error that the required 'timestamp' field is missing. [ { "id":"4b2c4d09-31e2-4fe2-b767-3868efbdcda1", "channel": {"add": "preet"}, "channel": {"add": "adam"} } ] Everything I've found so far indicates that in JSON this technically appears to be allowed, but there isn't any consistency in how any particular library might interpret it. Using the more obviously correct format works without error. [ { "id":"4b2c4d09-31e2-4fe2-b767-3868efbdcda1", "channel": {"add": "preet"} }, { "id":"4b2c4d09-31e2-4fe2-b767-3868efbdcda1", "channel": {"add": "adam"} } ] Full schema attached, but the following are the only required fields: <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" /> <field name="hive" type="string" indexed="true" stored="true" required="true" multiValued="false" /> <field name="at" type="date" indexed="true" stored="true" required="true" multiValued="false" omitNorms="true" /> <field name="timestamp" type="long" indexed="false" stored="true" required="true" multiValued="false" omitNorms="true" /> <field name="type" type="text_ws" indexed="true" stored="true" required="true" multiValued="false" omitNorms="true"/> <field name="message_id" type="string" indexed="true" stored="true" required="true" multiValued="false" omitNorms="true" /> Channel field: <field name="channel" type="text_ws" indexed="true" stored="true" required="false" multiValued="true" omitNorms="true"/> When I have a bit, I will try to reproduce with a minimally representative schema, but hopefully you can determine the reason it's parsing the way it is and have it generate a better error. -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org