Bringing together the Apache Cassandra experts from the community and DataStax.

Want to learn? Have a question? Want to share your expertise? You are in the right place!

Not sure where to begin? Getting Started

 

question

snarksliveshere avatar image
snarksliveshere asked Erick Ramirez commented

Ошибка because a collection ... has already been used in the past

Приветствую!

Ловлю ошибку на версии кассандры 3.11.4

у меня есть кастомный тип

CREATE TYPE IF NOT EXISTS custom_type (
    custom_id text,
    custom_type text
    );

который в миграции я добавляю к существующей таблице tbl

ALTER TABLE tbl ADD new_field map<text, frozen<custom_type>>;

и первый раз это работает хорошо.

далее, допустим, я откатываю миграцию и удаляю это поле из таблицы,

alter table tbl drop new_field;

и накатываю ее заново

ALTER TABLE tbl ADD new_field map<text, frozen<custom_type>>;

и вот тут получаю ошибку

InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot add a collection with the name custom_type because a collection with the same name and a different type (map<text, frozen<tuple<text, text>>>) has already been used in the past"

т.е. ситуация такова, что я не могу накатить второй раз это поле с этим же именем, так как я уже его использовал в прошлом. Хотя поле из таблицы я снес, когда откатывал миграцию.

Подскажите, пожалуйста, есть ли способ решить эту проблему, чтобы я спокойно мог накатывать и откатывать миграции с учетом использования этого поля?


cassandra
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

Erick Ramirez avatar image
Erick Ramirez answered Erick Ramirez commented

This isn't a bug. By design, it is not possible to add a collection with the same name as another collection that has been dropped if it has a different type.

The Cassandra storage engine was completely refactored in 3.0 (CASSANDRA-8099) and a lot of validation has been put in place to make sure that type mismatches between the data on disk and table schema do not occur.

For example, as part of the refactoring the SerializationHeader class only retrieves the column names from the metadata (see SerializationHeader.toHeader() method in C* 3.11.4) and ignores the kinds of columns they are, i.e. regular or static. If a column's kind is changed via ALTER TABLE ... DROP then eventually ADD, the header could be interpreted incorrectly and may lead to CorruptSSTableException or data corruption (CASSANDRA-14843). The same goes for collections where the type must match or serialization of the data will fail and lead to corruptions.

For these reasons, rolling back and rolling forward schema changes cannot be done in Cassandra since it breaks the validations in place that prevents data corruption. Cheers!

2 comments Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Erick, Thanks a lot, Its very helpful!

0 Likes 0 ·

You're welcome. I'm glad you found it helpful. Cheers!

0 Likes 0 ·