Re: child documents anyone?

Hi Dima, If your schema is configured correctly for atomic updates, you can add child documents atomically as well. If you want to add/replace/delete individual child documents, you'll have to use the JSON request format because those updates aren't supported through XML (SOLR-12677

Re: child documents anyone?

On 2022-12-23 3:28 AM, Thomas Corthals wrote: Hi Dima, If your schema is configured correctly for atomic updates, you can add child documents atomically as well. My reading of TFM is that atomic updates require all fields to be either stored or docValues = true and that is not the case with t

Re: child documents anyone?

PS on 2nd thought docValues = true seems to be the default for _nest_path_ so it's only _root_ (and _text_ but that's likely a braino in the default schema) that does not fit the requirement for atomic updates. Dima

Re: child documents anyone?

Hello, I barely understand what's the core issue here. I want to elaborate regarding end sentences about sql queries. I worked on ETL for structured model before. I found that external merge join (in SQL terms) works pretty awesome for indexers like these. We implemented it as a zipper join in DIH.

Re: child documents anyone?

On 2022-12-23 12:34 PM, Mikhail Khludnev wrote: ... I don't pitch migration to DIH ... This is going OT but the whole point is migration *from* DIH. I spent the last couple of weeks rewriting db-data-config.xml into (python) scripts and found a number of things that don't work out of the box

[SOLVED] Re: child documents anyone?

On 2022-12-23 3:28 AM, Thomas Corthals wrote: ... If your schema is configured correctly for atomic updates, you can add child documents atomically as well. So the answer was to make _root_ stored and docValues = true, and to delete _text_ that was there w/o the corresp. copyField by default.