Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.2, 3.3, 3.4, 3.5, 3.6, 4.0-ALPHA
    • Fix Version/s: 4.0-ALPHA, 3.6.1
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Improve IW#addDocuments(...) javadoc.
      Describer how blocks can be used regarding to index updates.

      1. LUCENE-4068.patch
        3 kB
        Martijn van Groningen
      2. LUCENE-4068.patch
        2 kB
        Martijn van Groningen

        Activity

        Hide
        Uwe Schindler added a comment -

        Bulk close for 3.6.1

        Show
        Uwe Schindler added a comment - Bulk close for 3.6.1
        Hide
        Martijn van Groningen added a comment -

        Committed to trunk and 3.6 branch.

        Show
        Martijn van Groningen added a comment - Committed to trunk and 3.6 branch.
        Hide
        Martijn van Groningen added a comment -

        True, that isn't atomic.

        Show
        Martijn van Groningen added a comment - True, that isn't atomic.
        Hide
        Yonik Seeley added a comment -

        Right now for updating the deleteDocuments(query) method should be used, before using updateDocuments(...) / addDocuments(...)

        Sure - but my point is that isn't atomic. That's why the updateDocument* methods exist in the first place (as opposed to doing separate deletes and then adds).

        Show
        Yonik Seeley added a comment - Right now for updating the deleteDocuments(query) method should be used, before using updateDocuments(...) / addDocuments(...) Sure - but my point is that isn't atomic. That's why the updateDocument* methods exist in the first place (as opposed to doing separate deletes and then adds).
        Hide
        Martijn van Groningen added a comment -

        Yes... someone could delete a parent without deleting its children. I guess that this a responsibility of the application using Lucene. Right now for updating the deleteDocuments(query) method should be used, before using updateDocuments(...) / addDocuments(...)

        The updateDocuments method that uses the delQuery could include a ToChildBlockJoinQuery instance (as part of a boolean query) that would matches to the children documents (in case a parent document were to be deleted). However this logic would then still be the apps responsibility.

        Show
        Martijn van Groningen added a comment - Yes... someone could delete a parent without deleting its children. I guess that this a responsibility of the application using Lucene. Right now for updating the deleteDocuments(query) method should be used, before using updateDocuments(...) / addDocuments(...) The updateDocuments method that uses the delQuery could include a ToChildBlockJoinQuery instance (as part of a boolean query) that would matches to the children documents (in case a parent document were to be deleted). However this logic would then still be the apps responsibility.
        Hide
        Yonik Seeley added a comment -

        you cannot delete the parent w/o deleting all of its children

        Atomic update seems a bit tricky...
        Perhaps this

          public void updateDocuments(Term delTerm, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException {
        

        should be something like

          public void updateDocuments(Iterable<Term>, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException {
        

        or perhaps even more generic:

          public void updateDocuments(Query delQuery, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException {
        
        Show
        Yonik Seeley added a comment - you cannot delete the parent w/o deleting all of its children Atomic update seems a bit tricky... Perhaps this public void updateDocuments(Term delTerm, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException { should be something like public void updateDocuments(Iterable<Term>, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException { or perhaps even more generic: public void updateDocuments(Query delQuery, Iterable<? extends Iterable<? extends IndexableField>> docs, Analyzer analyzer) throws CorruptIndexException, IOException {
        Hide
        Martijn van Groningen added a comment -

        Maybe instead of ". Also when documents inside a block are deleted" say ", even when child documents within a block are deleted"? (Ie, one sentence not two, and add "child" since you cannot delete the parent w/o deleting all of its children).

        Done.

        Also, can we not change the imports to wildcards?

        Done. My IDE did this on the fly...

        Show
        Martijn van Groningen added a comment - Maybe instead of ". Also when documents inside a block are deleted" say ", even when child documents within a block are deleted"? (Ie, one sentence not two, and add "child" since you cannot delete the parent w/o deleting all of its children). Done. Also, can we not change the imports to wildcards? Done. My IDE did this on the fly...
        Hide
        Michael McCandless added a comment -

        Looks good!

        Maybe instead of ". Also when documents inside a block are deleted" say ", even when child documents within a block are deleted"? (Ie, one sentence not two, and add "child" since you cannot delete the parent w/o deleting all of its children).

        Also, can we not change the imports to wildcards?

        Show
        Michael McCandless added a comment - Looks good! Maybe instead of ". Also when documents inside a block are deleted" say ", even when child documents within a block are deleted"? (Ie, one sentence not two, and add "child" since you cannot delete the parent w/o deleting all of its children). Also, can we not change the imports to wildcards?
        Hide
        Martijn van Groningen added a comment -

        Added better description how to deal with updates.

        The javadoc also states that future merging might not preserves blocks. Currently this isn't the case. Is this still true for upcoming SegmentMerger implementations? Maybe when this will be the case then better protection should be in place. Like storing the document blocks in the index.

        Show
        Martijn van Groningen added a comment - Added better description how to deal with updates. The javadoc also states that future merging might not preserves blocks. Currently this isn't the case. Is this still true for upcoming SegmentMerger implementations? Maybe when this will be the case then better protection should be in place. Like storing the document blocks in the index.

          People

          • Assignee:
            Unassigned
            Reporter:
            Martijn van Groningen
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development