[ 
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)

Reply via email to