On 7 September 2016 at 11:52, Mikhail Khludnev <[email protected]> wrote:
>> *) Do we need to document this as a limitation?
>
> Yes. Sure. But it's nowhere promised that update processors are applied on
> children.
I feel this violates the expectation of least surprise. For example, I
have discovered this issue by creating a sample dataset that ended-up
with a blank Date field in the child record. So, I figured this is
easy to fix Solr side by just adding RemoveBlankField URP. And.... it
did not work. Took me an hour to figure out that _none_ of the URPs
work at all. More importantly, it means we have no solutions for the
child documents for all those problems we solved over time with URPs.
Which we need to document and/or fix.
>> *) Do we need to fix it individually or there is a smart way to do it
>> centrally?
> Probably yes, but I prefer to aim someones real life challenge, than solve an
> abstract
> common sense problem. eg.
> how to apply a processor to children only but not to parent? Another case is
> ID generation
> - it's often required
> to generate it for parent but then implicitly propagate to children, but it
> requires paradigm
> shift:
> uniqueKey should be assigned on a block not a single document. This will fix
> when
> childless docs are mixed with blocks, etc.
> Perhaps, it make sense to create a processed which applies a certain chain of
> processors
> to children docs only?
Ok, these are interesting questions that can apply to specific URPs.
This suggests to me that each one (or each group) should be deal with
separately.
> Frankly speaking, block support are yet raw, and this limitation is not
> considered
> significant at comparison with other ones.
Well, we support them in XML, JSON, DIH, queries, etc. It may be raw
but it is usable and people are using it. So - to me - it is a valid
issue and worth thinking about.
Regards,
Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
