[
https://issues.apache.org/jira/browse/CASSANDRA-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470072#comment-13470072
]
Sylvain Lebresne commented on CASSANDRA-4684:
---------------------------------------------
All I'm saying is that there is a lot of case where a client needs to access
the schema. And for some tools, like an eclipse plugin for instance, they would
need to access the schema all the time (to offer say completion or validation).
Now you don't need this to access the schema, you query the system table.
However, if you do need to access the schema often, how do you do that? Well,
either you query the database every damn time, and your plugin/tool/code will
be super slow. Or, more likely, you cache the schema client side and implement
some regular polling to refresh that cache. Which works, mostly, but has the
defaults of polling: should you poll often or not? If you poll too often it's
inefficient, if you poll not often enough you'll provide a bad user experience.
Don't get me wrong, I'm not pretending that this is the worst problem database
face today, but that is not far fetched either and all this ticket does is to
provide a better solution to that problem. So why wouldn't we give people a
better solution if we can? And we can very easily. It's not like this small
patch touch any sensible part of the code, or somehow makes parts of the code
unreadable (at least to me it seems like a very minor addition).
I also note that the patch don't even impose anything on clients implementors
since events are optional (and optional by type of events).
As for libpq, as I said, this patch is an optimization so the fact that libpq
don't support it is not a proof that it's useless either. And as a side note,
and while I'm not expert in libpq, it has an aynchronous notification mechanism
and I wouldn't be surprised that along with some simple trigger you can very
easily have schema change notifications (does the eclipse plugin uses that if
that does work? I don't know and frankly I don't care).
> 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
