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

DDL syntax to change (not) nullable state of columns [CORE1180] #1606

Closed
firebird-automations opened this issue Mar 27, 2007 · 20 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Pierre Yager (pierrey)

Relate to CORE1684
Is duplicated by CORE2464
Is related to QA505

Votes: 4

I checked this old document related to IB6 :

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_60_sqlref#RSf47768

So I'm not sure if this already exists but since I never found a way to achieve this using DDL SQL I suggest you add a way to alter the nullable/not nullable state of an EXISTING column.

Somewhat like :

ALTER TABLE [table_name]
ALTER COLUMN [column_name] [TO BE] [NOT] NULL[ABLE];

For now I have to create some "upgrade scripts" to create a temporary column, move existing data, drop old one and change the new one's name.

Some voodoo tools like IBExpert knows some magic SQL that do the trick.

Can't that be done the official way ?

Commits: edb4192 6479022 79caf4e 0faabd1 0145996 ed0e0da FirebirdSQL/fbt-repository@2bdba17 FirebirdSQL/fbt-repository@47a6da0

====== Test Details ======

Several tests exist that covers this functionality.
1) Tests that manipulates with NULL fields/domains and check results:
CORE1518 Adding a non-null restricted column to a populated table renders the table inconsistent
CORE4453 (Regression: NOT NULL constraint, declared in domain, does not work)
CORE4725 (Inconsistencies with ALTER DOMAIN and ALTER TABLE with DROP NOT NULL and PRIMARY KEYs)
CORE4733 (Command "Alter table <T> alter TYPE <C> <DOMAIN_WITH_NOT_NULL" does not verifies data in column <C> and makes incorrect assignments in <C> to ZERO / JULIAN_DATE / ASCII(0) for types INT, TIMESTAMP and VARCHAR)

2) See also tests for:
CORE0304, CORE3085 (alter domain set/drop not null);
CORE0907, CORE4466(alter table <T> alter column <C> set not null);

@firebird-automations
Copy link
Collaborator Author

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Version: 2.1 Initial [ 10160 ]

Version: 2.1.0 [ 10041 ] =>

@firebird-automations
Copy link
Collaborator Author

Commented by: Mirco Malaguti (mirmalag)

Hi Pierre and Paul.
That's a minor deficiency. Nontheless it requires some boring workaround as you pointed out.
I vote for the improvement, adding that the application of the command should leave the database in a consistent state, otherwise an error should be returned. I agree that this similar inconsistent state can occur when you add a NOT NULL column without a default value.
Someone has argued about this point. My position is that no valid operation should leave an inconsistent state by design.
Maybe it's possible to add an "ASSIGN <value> TO NULLS" clause for those cases.

Thank you

Mirco

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE1684 [ CORE1684 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11714 ] => Firebird [ 15524 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Link: This issue is duplicated by CORE2464 [ CORE2464 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Fix Version: 3.0 Initial [ 10301 ]

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

Fix Version: 3.0 Initial [ 10301 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA505 [ QA505 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Commented by: PizzaProgram Ltd. (szakilaci)

Please re-OPEN this case, because since Firebird 3.0 > this workaround does not work any more!
1.] -- This works on FB 1.0, 2.0, 2.1, 2.5 :
update rdb$relation_fields set rdb$null_flag = null /* or 0 */
where rdb$relation_name = '<TableName>'
and rdb$field_name = '<FieldName>'
FB3 disabled the possibility to alter system tables.

We need a solution for this that works on ALL versions of FB the same way. (from 1.5- to 3.x)

Tried everything, like:
2.]
alter table rendeles_tetelek drop constraint (
select rc.rdb$constraint_name
from rdb$relation_constraints rc
join rdb$check_constraints cc
on rc.rdb$constraint_name = cc.rdb$constraint_name
where rc.rdb$constraint_type = 'NOT NULL'
and rc.rdb$relation_name = 'ORDER_DETAILS'
and cc.rdb$trigger_name = 'ITEM_ID')

3.]
alter table rendeles_tetelek alter column ITEM_ID set DEFAULT null;
-- no error msg, and constraint remained not null !!!

... but no solution.

Thank you,
László

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

There's no solution that would work the same way in all FB versions. You need to use either "update rdb$relation_fields" or "alter table", depending on FB version.

@firebird-automations
Copy link
Collaborator Author

Commented by: PizzaProgram Ltd. (szakilaci)

"alter table.." is currently NO SOLUTION to 3.0, because you can not insert the constraint_name directly, without an intermediate API. (See my not-working No.2 example).
(Maybe it would be possible with a very complicated EXECUTE BLOCK + EXECUTE STATEMENT procedure ... but most of the currently available Script-running API components can not handle those.)

Isn't it possible at least to make this format work on 3.x and than back-port to FB2.5:

alter table <table_name> alter column <column_name> set DEFAULT NULL;
?
Because this is causing currently a non-logical metadata setup at all versions. (having a not-null field with default-null).

Thanks ;)

@firebird-automations
Copy link
Collaborator Author

Commented by: PizzaProgram Ltd. (szakilaci)

By the way, these pages needs to be upgraded to exclude FB3 from "solutions and Tips" until this issue has been solved:

http://www.firebirdfaq.org/faq103/
https://www.firebirdsql.org/manual/nullguide-alter-pop-tables.html#nullguide-make-column-nullable

@firebird-automations
Copy link
Collaborator Author

Commented by: PizzaProgram Ltd. (szakilaci)

Please reopen this ticket and increase priority.
We still can not migrate to FB3.0 at any of our clients because of this problem.
(It's not just an "improvement" any more, but we need a FIX!)
Thank you very much.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

You don't need to know the constraint name:
alter table rendeles_tetelek alter column ITEM_ID drop not null;

@firebird-automations
Copy link
Collaborator Author

Commented by: PizzaProgram Ltd. (szakilaci)

It WORKS ! Thanks :)

please add these lines to the manual + FAQ !
(see links above)

Firebird 3.0 up:

ALTER TABLE <table_name> ALTER COLUMN <column_name> DROP NOT NULL;
-- removes the "not null" constraint

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

It's documented in the release notes:
https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-ddl-enhance.html#rnfb30-ddl-managenull

The Null Guide wasn't updated for FB v3 yet.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Covered by another test(s)

Test Details: Several tests exist that covers this functionality.
1) Tests that manipulates with NULL fields/domains and check results:
CORE1518 Adding a non-null restricted column to a populated table renders the table inconsistent
CORE4453 (Regression: NOT NULL constraint, declared in domain, does not work)
CORE4725 (Inconsistencies with ALTER DOMAIN and ALTER TABLE with DROP NOT NULL and PRIMARY KEYs)
CORE4733 (Command "Alter table <T> alter TYPE <C> <DOMAIN_WITH_NOT_NULL" does not verifies data in column <C> and makes incorrect assignments in <C> to ZERO / JULIAN_DATE / ASCII(0) for types INT, TIMESTAMP and VARCHAR)

2) See also tests for:
CORE0304, CORE3085 (alter domain set/drop not null);
CORE0907, CORE4466(alter table <T> alter column <C> set not null);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants