I’ve noticed when using the gocql driver that, by default, my client will register for TOPOLOGY_CHANGE, STATUS_CHANGE, and SCHEMA_CHANGE events. I can disable them using the driver, but I fear that might be a bad idea. How exactly do clients use these events? Doesn’t statement caching solve most of the problems with topology/schema changes?
These events are part of CQL standard, see section 4.2.6. “Event” in Apache Cassandra | Apache Cassandra Documentation. This way the driver stays in sync with the db. If by statement caching you mean that some CQL queries are cached, then it’s not enough, because these don’t reflect the cluster state.
2 Likes
Hey Piotr, thanks for taking the time to reply! I do have one follow up question: is the driver keeping track of schema changes? It seems weird to me that the driver is notified of all schema changes, even if they may be related to a table/view that the driver is not using. Is there a reason why it needs to know everything that’s going on across the cluster?
The driver is notified about all schema changes, but what it is doing this this information is different for every type of event. For most of them it just clears the information about schema for given keyspace (see: gocql/events.go at master · scylladb/gocql · GitHub). Only for schemaChangeKeyspace it does some additional work if tokenAwarePolicy is used (for other policies this is ignored).
3 Likes