XWIKI-22323: Refactoring operation should wait for the Solr index to be empty before proceeding #3403
Conversation
…be empty before proceeding * Introduce a new ReadyIndicator interface that allows waiting for the link index to become ready while getting a progress percentage. * In the BackLinkUpdaterListener, wait for the index to become ready when a job is active and display the indexing progress. * Provide a ready indicator including indexing progress in the Solr indexer. * Add some tests.
xwiki-platform-core/xwiki-platform-link/src/main/java/org/xwiki/link/LinkIndexingStatus.java
Outdated
Show resolved
Hide resolved
...i-platform-search-solr-api/src/main/java/org/xwiki/search/solr/internal/api/SolrIndexer.java
Outdated
Show resolved
Hide resolved
...oring-api/src/main/java/org/xwiki/refactoring/internal/listener/BackLinkUpdaterListener.java
Outdated
Show resolved
Hide resolved
…be empty before proceeding * Remove leftover LinkIndexingStatus.
…be empty before proceeding * Fix some math problems in the progress calculation. * Don't directly inject the link store into the link update listener to avoid early initialization.
…be empty before proceeding * Use Future<Void> for the ready indicator as there is no result value.
…be empty before proceeding * Move the ReadyIndicator to the store API.
…be empty before proceeding * Separate the SolrIndexerReadyIndicator from the DefaultSolrIndexer and add tests. * Restore the original coverage.
…be empty before proceeding * Fix the logic for updating progress steps.
…be empty before proceeding * Modernize the jobRunner JavaScript code * Continue polling the job status when the job is waiting to detect when a question is answered in the background (by another browser tab or on the server).
…be empty before proceeding * Add support in rename and delete job requests to indicate if the job should wait for indexing to finish. * Ask the user after 10 seconds if the refactoring should wait for link indexing to finish. * Add unit tests.
…be empty before proceeding * Add an integration test.
…be empty before proceeding * Update since-versions from 16.8.0RC1 to 16.8.0.
|
After waiting for 10 seconds, a question is now displayed:
The waiting for the index continues in the background and when the indexing finishes before the user responds, the question is dismissed. This behavior (as well as the two options in the questions) is also tested in an integration test. This whole thing became a lot bigger than I originally imagined. |
| * @since 15.10.13 | ||
| */ | ||
| @Unstable | ||
| public boolean isWaitForIndexing() |
There was a problem hiding this comment.
Shouldn't MoveAttachmentRequest have a true by default #isWaitForIndexing() too ? (since we refactor links to the moved attachments AFAIK, in MovedAttachmentListener, use case which seems to be missing in your pull request right now).
I think a EntityRequest#isWaitForIndexing (false by default) would make sense (DeleteRequest, AbstractCopyOrMoveRequest and MoveAttachmentRequest would just overwrite the default value to be true instead of false). Would things like the code in BackLinkUpdaterListener easier at least.
| @@ -185,6 +190,12 @@ public Set<EntityReference> resolveBackLinkedEntities(EntityReference reference) | |||
| return references; | |||
| } | |||
|
|
|||
| @Override | |||
| public ReadyIndicator waitReady() | |||
There was a problem hiding this comment.
I'm wondering why one API uses "waitReady" and the other "getReadyIndicator" for apparently the same thing.
This looks good. It would be even nicer to explain that this is about all the pages in the wiki and not just the current page (it' not 100% clear IMO) and to display the indexing counter in the format (N/P where P is the total items to index and N the number of already indexed ones). Thanks a lot Michael for this work, sorry it's taking more time than planned though. |
Jira URL
https://jira.xwiki.org/browse/XWIKI-22323
Changes
Description
Clarifications
Screenshots & Video
Executed Tests
Expected merging strategy