[
https://issues.apache.org/jira/browse/SOLR-11054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124478#comment-16124478
]
Hoss Man commented on SOLR-11054:
---------------------------------
bq. So in AutoCommitTest.testMaxDocs() we actually test for one more thing. All
indexed docs are searchable, therefore my opinion for
testSoftAndHardCommitMaxDocs() is we also should add this check. ...
Ok -- but the key questions then are:
# _should_ we really be testing searchability in these tests? the point of the
test isn't really to test anything about searchers/searching, it's about
testing autocommit -- all that should matter is if the commits actually happen.
# _if_ we're going to include searchability in these tests, then how do we do
it robustly w/o getting false failures? ... if you look at the unreliable
failures from AutoCommitTest, most of them come from asserts that attempt to
verify correct behaviour by executing a "search" against the docs that it
expects to have been autocommitted -- we shouldn't just copy that test logic as
is from AutoCommitTest to SoftAutoCommitTest.
...hence my question asking for clarification/illumination as to how you
suggested we should "assert that all docs from 0 -> softCommitMaxDocs must be
searchable" -- _in a reliable way_ and my suggestion that we do it in a new
(sibling) sub-task so the change can be tracked/assessed independently.
> Add SoftAutoCommitTest.testSoftAndHardCommitMaxDocs
> ---------------------------------------------------
>
> Key: SOLR-11054
> URL: https://issues.apache.org/jira/browse/SOLR-11054
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Attachments: SOLR-11054.patch, SOLR-11054.patch
>
>
> SoftAutoCommitTest should have a testSoftAndHardCommitMaxDocs that checks the
> maxDocs option for autocommit using the same monitor polling used by other
> existing SoftAutoCommitTest tests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
