On 8/29/2024 09:27, org.apache.s...@io7m.com wrote:
The client API allows for specifying input documents to be indexed.For example: final var document = new SolrInputDocument(); document.addField("x", "a"); document.addField("y", "b"); document.addField("z", "c"); client.add(collection, document); If there is a schema on the server-side that gives the types of "x", "y", and "z", then they will be assigned the correct types when the document is indexed. However, if those fields _aren't_ in the schema, then they'll almost certainly be assigned some kind of text type as a fallback.
<snip>
The documentation for addField() says: " Add a field value to any existing values that may or may not exist. The class type of value and the name parameter should match schema. xml. schema. xml can be found in conf directory under the solr home by default. Params: name – Name of the field, should match one of the field names defined under "fields" tag in schema. xml. value – Value of the field, should be of same class type as defined by "type" attribute of the corresponding field in schema. xml. " I assume that "of same class type" is referring to the various solr.* types such as solr.UUIDField, solr.BoolField, and so on. This documentation already seems incorrect because I'm clearly passing string constant values above and they're being accepted.
You are mixing things up as to exactly what "class" means here. In the schema, the class element in a fieldType definition does indeed refer to the solr.* classes you have mentioned. In SolrJ code, those classes will not be used, as they are a part of the core Solr server-side code, not included in SolrJ.
In almost all cases, the data types used in SolrJ code should be the most primitive class or variable type you can find to represent the data ... String, int, Integer, etc.
Thanks, Shawn
