[
https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000239#comment-13000239
]
Mark Harwood commented on LUCENE-2454:
--------------------------------------
Hi Paul,
I'm not sure I currently have an issue with merges as they just concatenate
established segments without interleaving their documents. This operation
should retain the order that is crucial to maintaining the
parent/child/grandchild relationships (unless something has changed in merge
logic which would certainly be an issue!). My main cause for concern is robust
control over flushes so parent/child docs don't end up being separated into
different segments at the point of arbitrary flushes.
I think your proposal here is related to a new (to me) use case where clients
can add a single new "child" document and the index automagically reorganises
to assemble all prior related documents back into a structure where they are
grouped as contiguous documents held in the same segment? Please correct me if
I am wrong.
Previously I have always seen this need for reorganisation as an application's
responsibility and a single child document addition required the app to delete
the associated parent and all old child docs, then add a new batch of documents
representing the parent, old children plus the new child addition. Given the
implied deletes and inserts required to maintain relationship integrity that
seems like an operation that needs to be done under the control of Lucene's
transaction management APIs rather than some form of special MergePolicy which
are really intended for background efficiency tidy-ups not integrity
maintenance.
As for the fields you outline for merging , generally speaking in applications
using NestedDocumentQuery and PerParentLimitedQuery I have found that for
searching purposes I already need to store:
1) A globally unique ID as an indexed "primary key" field on the top-level
container document
2) An indexed field with the same unique ID held in a different "foreign key"
field on child documents
3) An indexed field indicating the document type e.g "root" or "resume" and
"level1Child" or "employmentRecord"
I could be a little confused about your intentions - maybe should we start with
what problem we are trying to solve before addressing how we achieve it?
Cheers
Mark
> Nested Document query support
> -----------------------------
>
> Key: LUCENE-2454
> URL: https://issues.apache.org/jira/browse/LUCENE-2454
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Search
> Affects Versions: 3.0.2
> Reporter: Mark Harwood
> Assignee: Mark Harwood
> Priority: Minor
> Attachments: LuceneNestedDocumentSupport.zip
>
>
> A facility for querying nested documents in a Lucene index as outlined in
> http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
