Hi all,
this is more o a dev question, but posting here to a wider audience.
Due to overzealous trimming on my part, I have a schema without
`dynamicField name="*_str"` in it. Inserting a child document
```
{
"id" : "P1",
"C1": {
"add" : {
"id" : "P1!C1",
...
}
}
}
```
throws a `o.a.s.h.RequestHandlerBase
org.apache.solr.common.SolrException: copyField dest :'C1_str' is not an
explicit field and doesn't match a dynamicField` because
- "C1" is a "pseudo-field" not defined in teh schema, and
- the "add-schema-fields" UpdateProcessor by default tries to copy 256
chars of string and "text_general" fields into "*_str".
So the question: why?
It's highly unlikely that the first 256 chars of a child document are in
any way useful.
Should it be noted in TFM that if you use the default(-ish) config and
child documents, this copyfield'ing will happen?
Are there any larger implications for turning off
"add-unknown-fields-to-the-schema" chain? -- we never run "schemaless"
as all that does is create an elastic mess.
As best I can tell, pseudo-fields do not have a type, so I can't define
them in the schema and bypass that update chain. Is it a bug that they
are treated as string by the update processor?
(This is Solr-8.11 BTW, do pseudo-fields have a type in 9.x?)
Thoughts?
Dima
