Details
-
Improvement
-
Status: Resolved
-
Normal
-
Resolution: Won't Fix
-
None
-
None
Description
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.