Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CREATE TABLE WITH ID #2059

Closed
slivne opened this issue Feb 5, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@slivne
Copy link
Contributor

commented Feb 5, 2017

@argenet

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

For this feature/fix to work, we need to support CommitLog Archiver which is currently not there:
https://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configLogArchive_t.html

@avikivity

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

It can be implemented independently, it just won't be as useful.

archive_command looks really nasty. We should allow specifying a commitlog archive directory and scylla will copy or rename the file according to circumstance.

@avikivity

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

Note: WITH ID is still useful for creating internal tables.

@tgrabiec tgrabiec closed this in 1fc0c60 Dec 6, 2017

mundaym added a commit to linux-on-ibm-z/scylla that referenced this issue Dec 8, 2017

Support "CREATE TABLE WITH id" command.
Fixes scylladb#2059

Signed-off-by: Vladimir Krivopalov <vladimir@scylladb.com>
Message-Id: <92874a2bf1b4e79ef9f05875b3fa42804d17833c.1512508924.git.vladimir@scylladb.com>

avikivity added a commit that referenced this issue Oct 2, 2018

service/migration_manager: Validate duplicate ID in time
We allow tables to be created with the ID property, mostly for
advanced recovery cases. However, we need to validate that the ID
doesn't match an existing one. We currently do this in
database::add_column_family(), but this is already too late in the
normal workflow: if we allow the schema change to go through, then
it is applied to the system tables and loaded the next time the node
boots, regardless of us throwing from database::add_column_family().

To fix this, we perform this validation when announcing a new table.

Note that the check wasn't removed from database::add_column_family();
it's there since 2015 and there might have been other reasons to add
it that are not related to the ID property.

Refs #2059

Signed-off-by: Duarte Nunes <duarte@scylladb.com>
Message-Id: <20181001230142.46743-1-duarte@scylladb.com>

duarten added a commit that referenced this issue Apr 17, 2019

service/migration_manager: Validate duplicate ID in time
We allow tables to be created with the ID property, mostly for
advanced recovery cases. However, we need to validate that the ID
doesn't match an existing one. We currently do this in
database::add_column_family(), but this is already too late in the
normal workflow: if we allow the schema change to go through, then
it is applied to the system tables and loaded the next time the node
boots, regardless of us throwing from database::add_column_family().

To fix this, we perform this validation when announcing a new table.

Note that the check wasn't removed from database::add_column_family();
it's there since 2015 and there might have been other reasons to add
it that are not related to the ID property.

Refs #2059

Signed-off-by: Duarte Nunes <duarte@scylladb.com>
Message-Id: <20181001230142.46743-1-duarte@scylladb.com>
(cherry picked from commit 7ba944a)

amoskong pushed a commit to amoskong/scylla that referenced this issue May 8, 2019

service/migration_manager: Validate duplicate ID in time
We allow tables to be created with the ID property, mostly for
advanced recovery cases. However, we need to validate that the ID
doesn't match an existing one. We currently do this in
database::add_column_family(), but this is already too late in the
normal workflow: if we allow the schema change to go through, then
it is applied to the system tables and loaded the next time the node
boots, regardless of us throwing from database::add_column_family().

To fix this, we perform this validation when announcing a new table.

Note that the check wasn't removed from database::add_column_family();
it's there since 2015 and there might have been other reasons to add
it that are not related to the ID property.

Refs scylladb#2059

Signed-off-by: Duarte Nunes <duarte@scylladb.com>
Message-Id: <20181001230142.46743-1-duarte@scylladb.com>
(cherry picked from commit 7ba944a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.