On 12/21/22 05:42, Shawn Heisey wrote:
I created the "save.fields" property and set it to "true" and added this
to my schema:
<field name="test" type="string" indexed="false"
stored="${save.fields:bleh}"/>
This did not throw an error on startup which I would expect if the
property were not available. A document indexed with the test field
does show the field in the result.
Turns out I set the field to false, not true. Which means that I am
actually seeing the same behavior you are.
But I know from the other experiment that the property is found, or it
would have thrown an error, but somehow it is going into the schema
object as true when I have defined it as false in the property.
I tried another experiment:
<field name="test" type="string" indexed="false" stored=""/>
And this resulted in the field being stored. Very odd, especially given
the outcome of the next experiment:
<field name="test" type="string" indexed="false" stored=""
default="${save.fields:bleh}"/>
And the newly indexed document has the value "bleh" in test instead of
"false".
Looks like property handling in the schema is broken, but broken in a
very weird way.
This is version 9.2.0-SNAPSHOT built from branch_9x.
Another note: I am having the same issue someone else on the list
mentioned, where it seems Solr is ignoring my uniqueKey and when I index
a document more than once it is not overwriting the doc, multiple copies
with the same ID are there.
Thanks,
Shawn
