cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4684) Binary protocol: inform clients of schema changes
Date Fri, 05 Oct 2012 15:36:02 GMT


Sylvain Lebresne commented on CASSANDRA-4684:

But it's very very little complexification. I mean, it's about zero added complexity client
side unless they want to care about optimizing that use case (and they are willing to, why
limit them?). And server side, it adds a few lines of code, sure, but I hardly see how it
"complexify" things.

bq. so let's put "push" in the YAGNI column until demonstrated otherwise

My problem with that is that this is that since there is an inferior workaround (polling or
taking the hit of query the schema each time), it's unclear we'll hear from client that would
benefit from that. Or we may only hear about that when lots of people have implemented that
less then inferior workaround. I agree that we shouldn't add feature just because we can,
but I really think that's not a case of that. Having to access the schema regularly client-side
feels hardly like a crazy thing people would need. Why not optimize it if it cost us nothing
(and again, I do think it cost us about nothing).
> Binary protocol: inform clients of schema changes
> -------------------------------------------------
>                 Key: CASSANDRA-4684
>                 URL:
>             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:

View raw message