[
https://issues.apache.org/jira/browse/CASSANDRA-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13605359#comment-13605359
]
Sylvain Lebresne commented on CASSANDRA-5358:
---------------------------------------------
Just to put a bit of perspective, I think this can kind of matter for people
doing integration tests (which might still qualify as antisocial).
Typically, if you end up doing:
{noformat}
DROP KEYSPACE k1;
CREATE KEYSPACE k2 ....;
CREATE TABLE foo ....;
{noformat}
then currently the create table will give you a "Invalid keyspace k1" error.
Now say the drop itself is separated, maybe that was the cleanup of the
previous test, then the error message could be a bit misleading (it's
definitively not a big deal, just saying that it's not about people dropping
their company keyspace because they got fired).
In fact, to give another example and justify why I opened the issue, I had
someone having a bug with the datastax java driver because he was doing
something like this:
{noformat}
session = cluster.connect("test");
session.execute("DROP KEYSPACE test");
session.execute("CREATE KEYSPACE test ...");
session.execute("CREATE TABLE foo ...");
session.execute("INSERT INTO foo ....");
PreparedStatement ps = session.prepare("SELECT * FROM foo ... ");
for (;;) {
session.execute(ps.bind(...));
// print result and sleep some
}
{noformat}
And while doing the infinite loop, he was stopping/restarting nodes, to check
everything continued to work. And it wasn't.
The reason being that on the initial drop, the driver was expecting C* to delog
the user. So when the select was prepared, the driver expected it to be fully
qualified (the driver doesn not parse queries, so when a query is prepared, he
remember the keyspace used for repreparing the query. In that case he was
remembering no keyspace). Anyway, when node were restarted later, the driver
tried re-preparing the quer but without setting the keyspace first and as a
consequence this failed.
I've currently changed the driver so that it match current Cassandra behavior,
i.e. to not "unlog" connections on drop, so it's not a blocker or anything.
Just wanted to justify why we want to decide clearly what we do. I'm also fined
doing what's simpler.
> Dropping a keyspace does not "delog" existing connections.
> ----------------------------------------------------------
>
> Key: CASSANDRA-5358
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5358
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Priority: Minor
>
> Currently, if we drop a keyspace k, this does not reset the "current
> keyspace" from the clientState if it is k.
> Concretely, this means that if someone drop a keyspace k and then try any
> query that doesn't have a fully qualified keyspace, he we get a message "k
> doesn't exist" instead of the more user-friendly "you are not logged in any
> keyspace".
> I believe that delogging connections on keyspace drop would be the right
> thing to do, but it would probably require tracking open connections more
> than we do now. So I'd be fine saying we keep the status quo, but it's
> important that we decide which behavior we implement so that client libraries
> know what to expect, so I wanted to bring it up.
--
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
