[jira] [Commented] (CASSANDRA-9967) Determine if a Materialized View is finished building, without having to query each node

["Joel Knighton (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-9967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180504#comment-15180504 ] 

Joel Knighton commented on CASSANDRA-9967:
------------------------------------------

Sorry for the delay.

utests and dtests look clean compared to upstream. The added dtests pass locally for me. A dtest that covers calling the command after dropping a view would be nice.

In SystemKeyspace
- Now might be a good time to fix the comment above {{finishViewBuildStatus}} that we discussed ("the build succeeded, but the view build failed")
- Changing {{viewBuiltReplicated}} to {{setViewBuiltReplicated}} better matches the naming convention used elsewhere in the class
- The {{forceBlockingFlush}} at end of {{viewBuiltReplicated}} is redundant with the call at the end of {{setViewBuilt}}

In QueryProcessor
- As we discussed, there's other improvements to be made in QueryProcessor for clarity. It seems to me that the {{executeInternal}} you added might not be appropriately named - it calls {{statement.execute}} rather than {{statement.executeInternal}}. (It's not entirely clear whether the internal in QueryProcessor.executeInternal is to reflect that it uses internal QueryState or executeInternal on PreparedStatement, but it seems to me to indicate the latter.)

In StorageService
- In {{getViewBuildStatuses}}, retrieving the {{hostIdToEndpoint}} map at a different time than calling {{getEndpointToHostIdMapForReading()}} opens up a race with changes in TokenMetadata that could result in the endpoint being null. It seems to me cleaner to retrieve the endpointToHostIdMapForReading and iterate over its entries rather than maintaining two separate maps.

> Determine if a Materialized View is finished building, without having to query each node
> ----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9967
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9967
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Alan Boudreault
>            Assignee: Carl Yeksigian
>            Priority: Minor
>              Labels: lhf
>             Fix For: 3.x
>
>
> Since MVs are eventually consistent with its base table, It would nice if we could easily know the state of the MV after its creation, so we could wait until the MV is built before doing some operations.
> // cc [~mbroecheler] [~tjake] [~carlyeks] [~enigmacurry]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)