[
https://issues.apache.org/jira/browse/SOLR-5211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041236#comment-15041236
]
Mikhail Khludnev commented on SOLR-5211:
----------------------------------------
I want to emphasize two things: multilevel nesting is out of scope so far, just
because we can't deal with the simplest single level parent/child case yet; I
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or
check are there children (btw, they can be commited yet).
We need to come up with universal routine which can handle all cases below via
the single API entry point [IW.updateDocuments(delTerm,
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
or establish the new one:
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself
just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for
childless, and {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.
IMHO, if we just allow $uniqueKey to span across a whole block (q=id:33 returns
a block of several docs), it would be nobrainer, which solves everything.
What I'm missing?
> updating parent as childless makes old children orphans
> -------------------------------------------------------
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
> Issue Type: Sub-task
> Components: update
> Affects Versions: 4.5, Trunk
> Reporter: Mikhail Khludnev
> Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> if I have parent with children in the index, I can send update omitting
> children. as a result old children become orphaned.
> I suppose separate \_root_ fields makes much trouble. I propose to extend
> notion of uniqueKey, and let it spans across blocks that makes updates
> unambiguous.
> WDYT? Do you like to see a test proves this issue?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
