Using Hue, how can I alter a table to make a prexisting column a primary key?
I check and things like :
ALTER TABLE table_name ADD CONSTRAINT colname PRIMARY KEY (cs_id);
is not syntactically correct.
NB: data is stored using Kudu file system.
First, Impala does not support alter contraint as an option in alter table.
Second, primary keys are very limited:
The primary key columns must be the first ones specified in the CREATE TABLE statement.
I don't think you can change the primary key after it has been defined. In Impala, the data is clustered (i.e. sorted) by the primary key, so any change would be quite expensive.
You probably need to recreate the table and reload it with data.
When you are storing as Kudu, you need to consider that the PK columns need to be all created at the creation of the table.
Impala does not support altering primary keys.
I'm afraid you need to delete and create the table again.
Related
How to drop composite key in liquibase using SQL commands ? My composite key doesn't have a name for it.
I tried searching liquibase documentation but it says about primary keys only.
A composite key is a primary key. So if you found a way to drop a primary key, then use it.
As you want to use SQL command, not Liquibase XML, JSON etc., then this is a question how to drop a composite key in SQL. An answer depends on a database engine you use. For example in MySQL, you can do that like this:
ALTER TABLE CITIES DROP PRIMARY KEY;
A primary key from the CITIES table will be deleted even if it is a composite key.
To make it runnable from Liquibase, you just add a comment line with Liquibase meta data. For example:
--changeset Harsh:1
ALTER TABLE CITIES DROP PRIMARY KEY;
I'm creating a copy of a table using the CREATE TABLE... LIKE statement in Redshift, and the copy is working, but primary key is not being preserved.
CREATE TABLE new_table (LIKE orig_table);
Am I missing a parameter that should be specified to ensure this works?
Thanks
From CREATE TABLE
Tables created with the LIKE option don't inherit primary and foreign key constraints. Distribution style, sort keys, BACKUP, and NULL properties are inherited by LIKE tables, but you can't explicitly set them in the CREATE TABLE ... LIKE statement.
I have added a table to a database called settings. This table has a column called id (integer) which is the pirmary key. I have also added a column called settingsID to a table called sessions. What I want to do is add a foreign key to settingsID which references the primary key.
I don't want to create a new table as it is already created. All I want to do is to references the id from the settings table in settingsID which is in sessions table.
ALTER TABLE Sessions ADD FOREIGN KEY (_SettingsID) REFERENCES settings (id)
Here is my error:
near "FOREIGN": syntax error
Can someone tell me the right way to approach this?
Short answer: you can't.
This is documented as part of the SQL Features That SQLite Does Not Implement:
Only the RENAME TABLE, ADD COLUMN, and RENAME COLUMN variants of the ALTER TABLE command are supported. Other kinds of ALTER TABLE operations such as DROP COLUMN, ALTER COLUMN, ADD CONSTRAINT, and so forth are omitted.
Bold emphasis is mine.
So basically you would need to create the constraint at the time when the table is created. For your use case, one solution would be to:
create a new table (with the foreign key constraint)
copy the data from the old table
drop the old table (or better yet, rename it, so you have a backup)
rename the new table
I am trying to replicate a table using CTAS clause in redshift by additionally specifying a primary key to the table.
Tried below syntax but no luck. However, I was able to specify DISTKEY/SORTKEY using the same syntax
create table date_dim
PRIMARY KEY(date_key)
--DISTKEY ( date_key )
as
select date_key,
calendar_date,.....;
I want to use primary key as part of merge logic I am designing in my flow.
TIA!
Many people consider primary and foreign keys in Redshift to be an anti-pattern (because they're unenforced), but my team built a small tool (a Python script) that supports this scenario.
You write your select statement in a normal SQL file, define primary key, foreign keys, distkey, etc in a YAML configuration file, and then use the script to generate (and optionally execute) SQL to create and populate the table.
We also include an Airflow operator to make it simple to schedule and automate this.
The repo is here, and we wrote a bit more about it on our team blog
You can only specify distkey and sortkey in CTAS . Here is the below link which describes what all options you can specify
Redshift CTAS
If the column you are wishing to dub as primary key is already non-nullable you can use this:
ALTER TABLE <table_name> ADD CONSTRAINT <a_name_for_this_constraint> PRIMARY KEY (<attribute_name>)
e.g.: ALTER TABLE member ADD CONSTRAINT pk_1 PRIMARY KEY (member_id);
Redshift doesn't support primary and foreign key constraints: http://docs.aws.amazon.com/redshift/latest/dg/t_Defining_constraints.html
I have a table on a iSeries(IBM-i/AS400) which has some constraints. The table is created with SQL like so, with a handful of foreign keys linking from other tables to this table (actual SQL has been a bit obfuscated here):
CREATE TABLE ABCLIB.ABCDE (
DEIDN INTEGER NOT NULL WITH DEFAULT,
DETTL VARGRAPHIC (50) ALLOCATE(25),
DETYP CHAR (1) NOT NULL WITH DEFAULT);
ALTER TABLE ABCLIB.ABCDE ADD PRIMARY KEY (DEIDN);
ALTER TABLE ABCLIB.ABCFG ADD FOREIGN KEY (FGDEK)
REFERENCES ABCLIB.ABCDE (DEIDN)
ON DELETE RESTRICT ON UPDATE RESTRICT;
ALTER TABLE ABCLIB.ABCHI ADD FOREIGN KEY (HIDEK)
REFERENCES ABCLIB.ABCDE (DEIDN)
ON DELETE RESTRICT ON UPDATE RESTRICT;
Now, much later, I will need to alter that table to add a field:
ALTER TABLE ABCLIB.ABCDE ADD COLUMN DEICN VARGRAPHIC (100) ALLOCATE(50)
Which results in this message:
Row or object ABCDE in ABCLIB type *FILE in use.
I have checked and there are definitely no object locks on this table at this time. When I check the joblog, I see this:
Constraint cannot be removed from file Q_AT000000.
Constraint(s) not removed from file Q_AT000000.
File ABCDE in ABCLIB not changed.
Row or object ABCDE in ABCLIB type *FILE in use.
Now, I could of course remove and re-add the constraints in question, but I feel like this should not be necessary. The column I am adding has nothing to do with the constraints. I believe this probably is a result of the fact that in fact OS400 (i5/OS) is not really altering the existing table but instead is creating a new table and copying data in, and that is probably where the pain comes in.
But is there a way to possibly suspend the keys and then resume them after the alter?
(Answers that do not involve doing this with SQL or suggest creating the table differently in the first place are not helpful as they are not applicable here...)
The answer is: I missed the fact that there was a lock on one of the tables that had a foreign key pointing to that table. Or, put more bluntly: I am an idiot!
Does Enabling or disabling referential constraints help?