worryg0d commented on code in PR #1926:
URL:
https://github.com/apache/cassandra-gocql-driver/pull/1926#discussion_r2720236432
##########
events.go:
##########
@@ -133,27 +133,42 @@ func (s *Session) handleEvent(framer *framer) {
}
func (s *Session) handleSchemaEvent(frames []frame) {
Review Comment:
I'm unsure if this is the right way to handle this. My understanding is that
`schemaChangeKeyspace` event is sent by Cassandra only in case when some DDL is
running for a keyspace. From the protocol doc:
https://cassandra.apache.org/doc/latest/cassandra/reference/native-protocol.html
```
An event pushed by the server. A client will only receive events for the
types it has REGISTERed to. The body of an EVENT message will start with a
[string] representing the event type. The rest of the message depends on
the
event type. The valid event types are:
...
"SCHEMA_CHANGE": events related to schema change. After the event type,
the rest of the message will be <change_type><target><options> where:
- <change_type> is a [string] representing the type of changed
involved.
It will be one of "CREATED", "UPDATED" or "DROPPED".
- <target> is a [string] that can be one of "KEYSPACE", "TABLE",
"TYPE",
"FUNCTION" or "AGGREGATE" and describes what has been modified
("TYPE" stands for modifications related to user types, "FUNCTION"
for modifications related to user defined functions, "AGGREGATE"
for modifications related to user defined aggregates).
- <options> depends on the preceding <target>:
- If <target> is "KEYSPACE", then <options> will be a single
[string]
representing the keyspace changed.
- If <target> is "TABLE" or "TYPE", then
<options> will be 2 [string]: the first one will be the keyspace
containing the affected object, and the second one will be the
name
of said affected object (either the table, user type, function,
or
aggregate name).
- If <target> is "FUNCTION" or "AGGREGATE", multiple arguments
follow:
- [string] keyspace containing the user defined function /
aggregate
- [string] the function/aggregate name
- [string list] one string for each argument type (as CQL type)
```
So, basically we're loosing informating about the **target**. Let's say we
dropped a table in a keyspace, then Cassandra will send an event to the clients
about that change. The problem here is that on each change, we call
`policy.KeyspacesChanged()`, which consists of two fields:
```
type KeyspaceUpdateEvent struct {
Keyspace string
Change string
}
```
So, we lost a target of the change, and this actually changes the behavior
of the API - previously gocql was notified on DDL run for individual keyspace,
and the current implementation notifies on each DDL runs including tables,
aggregates, etc.
Also, I don't think that just adding `Target` field to the
`KeyspaceUpdateEvent` is a good idea, because there could be custom
implementations of `HostSelectionPolicy` which could rely on old behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
