[
https://issues.apache.org/jira/browse/CASSANDRA-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470374#comment-13470374
]
Jonathan Ellis commented on CASSANDRA-4684:
-------------------------------------------
I still think this is premature complexification. As mentioned, our only real
prior art for schema caching is cli because it needs to for ASSUME; otherwise
query-schema-every-time is completely fast enough. Of course any such tool
will have to implement query-full-schema anyway to get initial state, so that's
the simplest possible solution. My gut is that this is probably adequate so
let's put "push" in the YAGNI column until demonstrated otherwise.
> Binary protocol: inform clients of schema changes
> -------------------------------------------------
>
> Key: CASSANDRA-4684
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4684
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.2.0 beta 1
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0 beta 2
>
> Attachments: 0001-Return-schema-change-infos.txt,
> 0002-Add-migration-events.txt
>
>
> It would be nice to inform clients when a schema change occurs as this would
> allow said client to maintain the current state of the schema, which might be
> useful/desirable. To allow that, we can:
> # return that a query has changed the schema (instead of simply a 'void'
> return), in the same spirit than CASSANDRA-3707.
> # add events notification on schema change.
> Just to be clear, the goal is only to inform that a change has occured, the
> client would still have to query the system table to know the exact content
> of the change, but at least it'll know when to do such query.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
