[
https://issues.apache.org/jira/browse/CASSANDRA-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398754#comment-13398754
]
Jonathan Ellis commented on CASSANDRA-3707:
-------------------------------------------
Quoting Rick from CASSANDRA-2478:
bq. Much of the pressure in the corporate world I live in is from teams that
are trying to use JDBC driver for C* in the same fashion and with the same BI,
ETL and statistics tools (Talend, Informatica, Datastage, SPSS, SAS) as they do
for relational solutions. Many of these tools are quite comprehensive in the
information they can display and use, so they are heavy users of the metadata
features of the driver. Returning no data for some functions often causes the
tooling to just give up, not to use what they have.
However, given that we've added this functionality to the 2478 driver, do we
need to mangle Thrift again to add it there too? (Since clients will need to
be updated to use the new information either way...)
> Add KeyspaceChange CqlResultType
> --------------------------------
>
> Key: CASSANDRA-3707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3707
> Project: Cassandra
> Issue Type: Sub-task
> Components: API
> Reporter: Jonathan Ellis
> Assignee: satish babu krishnamoorthy
> Labels: cql
> Fix For: 1.1.2
>
>
> High level clients want to handle failover and load balancing transparently
> to the application, which means not just connection pooling but moving an
> existing connection to another server if necessary. When this happens, the
> client needs to know what the active keyspace was before failover, so it can
> set it to the same one in the new connection.
> Currently some clients handle this by checking for "SET KEYSPACE" queries,
> which violates the design principle that clients shouldn't have to parse CQL.
> Adding a new CqlResultType (that is set in response to a SET KEYSPACE
> command) would make this unnecessary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
