Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 5 Oct 2012 18:16:48 +1100 (NCT)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <1178588255.4472.1349421408657.JavaMail.jiratomcat@arcas>
In-Reply-To: <673963644.96606.1348043467709.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (CASSANDRA-4684) Binary protocol: inform clients
 of schema changes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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