[
https://issues.apache.org/jira/browse/CASSANDRA-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532352#comment-13532352
]
T Jake Luciani commented on CASSANDRA-5063:
-------------------------------------------
This isn't renaming, this is like a unix soft link.
All it would be is a new system table
{code}
create table aliases (
alias_name text PRIMARY KEY,
keyspace_name text
);
{code}
CQL would add support like.
create KEYSPACE ALIAS prod ON prod2012;
Then when a request comes in we simply de-alias the keyspace in the coordinator.
---
Another use case for this is a backup recovery or rebuild of a corrupted data
keyspace. When you want to flip from the old to the new you don't want to
re-deploy all of your software with the new config. Most databases support
aliases so this is not a new idea.
The name could be said for table aliases. But we can leave that for another
ticket.
> Aliasing Keyspaces
> ------------------
>
> Key: CASSANDRA-5063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5063
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Carl Yeksigian
>
> The way we are working with our cassandra is that we have multiple keyspaces,
> each of them representing the same data in different forms. We would like to
> have a single name representing the current production keyspace, while we are
> working on backloading our development keyspaces.
> The proposed work flow would be:
> - create keyspace prod1
> - alias keyspace prod to prod1
> - create keyspace prod2
> - backload prod2
> - alias keyspace prod to prod2
> - drop keyspace prod1
> It would be really nice if we weren't referring to "prod1" and "prod2",
> rather always referencing "prod", and the aliasing would happen in Cassandra.
--
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
