Hi
This is a quite big topic, maybe it should be a topic for a blog post, etc.
I've spent some time working with customers on that, so here is my TLDR:
- You can add regular columns (not part of the primary key) to a table.
You must not to add the column with the same name as another dropped column
- this will lead to errors in commit log replay, and lead to problems with
data in existing SSTables.
- You can drop regular columns with some limitations:
- we can't drop columns that are part of the primary key (if you need to
do this, see the next section);
- It's not possible to drop columns on tables that have materialized
views, secondary or search indexes - if you still need to rename it, you
need to drop view or index, and re-create it after renaming;
- if you drop a column then re-add it, DSE does not restore the
values written before the column was dropped;
- It's not possible to change column type - this functionality did exist
in some versions, but only for "compatible" data types, but it was removed
from Cassandra as part of the CASSANDRA-12443, due the scalability
problems. Don't try to drop the column & re-add it again with a new type -
you'll get corrupt data. Actual changes in the column type should be done
by:
- adding a new column with desired type
- running migration code that will copy data from existing columns
- dropping the old column
- To support process continuity, applications may work with both
columns (read & write) during migration, and use only one after migration
happened.
- You can rename column that is the part of the primary key, but not the
regular column
- You can't change the primary key - you need to create a new table with
desired primary key, and migrate data into it.
- You can add new field to the UDT, and you can rename field in UDT, but
not drop it
there are some tools to support schema evolution, for example:
https://github.com/hhandoko/cassandra-migration
On Wed, Jul 15, 2020 at 8:39 PM Manu Chadha <manu.cha...@hotmail.com> wrote:
> Hi
>
>
>
> What is allowed and not allowed w.r.t altering Cassandra table schema?
>
>
>
> Creating the right schema seems like the most step w.r.t using Cassandra.
> Coming from relational background, I still struggle to create schema which
> leverages duplication and per-query table (I end up creating relationships
> between tables).
>
>
>
> Even if I am able to create a schema which doesn’t have relationship
> between tables for now, my application will evolve in future and I might
> then have to change the schema to avoid creating relationships.
>
>
>
> In that respect, what would I be able to change and not change in a
> schema? If I add a new field (non-key), then for existing values I suppose
> the value of that new field will be null/empty. But if I am allowed to make
> the new field an additional key then what will be the value of this key for
> existing data?
>
>
>
> Thanks
>
> Manu
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
--
With best wishes, Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
