[jira] [Commented] (CASSANDRA-7881) SCHEMA_CHANGE Events and Responses should carry the Schema Version

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-7881:
---------------------------------------------



I'm afraid moving {{Schema.updateVersion()}} before the schema is applied is wrong because that writes into the system tables and that is what client checks.  In practice, it means clients would consider the schema in agreement before it's actually true for all intent and purposes.

We can definitively compute the version sooner however, so we could compute it and pass it down to the migration notifications (but we'd only update it in {{Schema}} like we do now).

That said, I have some doubt about the issue tbh because:

bq. If you had the current version UUID then any node could be use to verify schema agreement.

I'm actually not sure that would be a good idea. Checking for the specific version returned would potentially break with concurrent schema change. It's reasonable to expect that nodes will settle on *a* version (assuming there isn't a very long and uninterrupted stream of schema updates), but it's not reasonable to expect they will settle on *the* version returned by any particular update in general. Imo, using the node on which the update was done is not enough of a big deal to risk a schema agreement wait lock with concurrent schema updates.

bq. This could then be exposed in the client APIs in order to bring much more precise awareness of the actual status of the schema on each node.

The same reasoning as above makes me wondering if that is such a good idea. The schema version can change at any time and is not terribly meaningful per-se, especially since schema changes are not linearized by C*, and I fear given that version too much exposure will just lead to misuses.

I don't strongly object to this ticket, but I do question how much useful it will be versus how likely it is to be misuse. I would tend to think it's not worth bothering.


> SCHEMA_CHANGE Events and Responses should carry the Schema Version
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-7881
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7881
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Michaël Figuière
>            Assignee: Robert Stupp
>            Priority: Minor
>              Labels: client-impacting, protocolv4
>             Fix For: 3.0
>
>         Attachments: 7881.txt
>
>
> For similar logging and debugging purpose as exposed in CASSANDRA-7880, it would be helpful to send to the client the previous and new schema version UUID that were in use before and after a schema change operation, in the {{SCHEMA_CHANGE}} events and responses in the protocol v4.
> This could then be exposed in the client APIs in order to bring much more precise awareness of the actual status of the schema on each node.



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