[
https://issues.apache.org/jira/browse/CASSANDRA-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8345.
-----------------------------------------
Resolution: Won't Fix
While we could do this in theory, having driver do an extra query to get the
details is really not a big deal so I don't think it's worth the additional
complexity for the binary protocol.
> Client notifications should carry the entire delta of the information that
> changed
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-8345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8345
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Michaël Figuière
> Labels: protocolv4
>
> Currently when the schema changes, a {{SCHEMA_CHANGE}} notification is sent
> to the client to let it know that a modification happened in a specific table
> or keyspace. If the client register for these notifications, this is likely
> that it actually cares to have an up to date version of this information, so
> the next step is logically for the client to query the {{system}} keyspace to
> retrieve the latest version of the schema for the particular element that was
> mentioned in the notification.
> The same thing happen with the {{TOPOLOGY_CHANGE}} notification as the client
> will follow up with a query to retrieve the details that changed in the
> {{system.peers}} table.
> It would be interesting to send the entire delta of the information that
> changed within the notification. I see several advantages with this:
> * This would ensure that the data that are sent to the client are as small as
> possible as such a delta will always be smaller than the resultset that would
> eventually be received for a formal query on the {{system}} keyspace.
> * This avoid the Cassandra node to receive plenty of query after it issue a
> notification but rather to prepare a delta once and send it to everybody.
> * This should improve the overall behaviour when dealing with very large
> schemas with frequent changes (typically due to a tentative of implementing
> multitenancy through separate keyspaces), as it has been observed that the
> the notifications and subsequent queries traffic can become non negligible in
> this case.
> * This would eventually simplify the driver design by removing the need for
> an extra asynchronous operation to follow up with, although the benefit of
> this point will be real only once the previous versions of the protocols are
> far behind.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
