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
Inconsistencies with ALTER DOMAIN and ALTER TABLE with DROP NOT NULL and PRIMARY KEYs [CORE4725] #5032
Comments
Modified by: @asfernandesassignee: Adriano dos Santos Fernandes [ asfernandes ] |
Commented by: @asfernandes Changing this bug title to reflect the current state of things. create domain d integer; recreate table test02(x integer not null); recreate table test02(x d not null); recreate table test02(x dn); recreate table test02(x dn not null); recreate table test02(x dn); alter domain dn set not null; |
Modified by: @asfernandessummary: Command "Alter table <T> alter <C> NULL" is allowed for column <C> which was already defined as PRIMARY KEY for <T> => Inconsistencies with ALTER DOMAIN and ALTER TABLE with DROP NOT NULL and PRIMARY KEYs |
Commented by: @asfernandes Now about this: recreate table test02(x dn not null); This incorrect thing is done by a system trigger that we have only the BLR code. Yes, we don't have a system trigger source code!!! |
Modified by: @asfernandesstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Beta 2 [ 10586 ] |
Commented by: @pavel-zotov Adriano, can you please clarify about this: === This incorrect thing is done by a system trigger that we have only the BLR code. Yes, we don't have a system trigger source code!!!Currently this code does *NOT* produce any error and table test02 will remain in the previous state: its field 'x' will be NOT null. I do the following:
-- and get: 1) STDOUT:
X (DM_02) INTEGER Not Null 2) STDERR: And 2nd question: I have empty database with ODS 12.0 that has been created 11-mar-2015, and if I run this query against this database than exception DOES appear. |
Modified by: @pavel-zotovAttachment: c4725-fdb-created-20150311-ods12-generation16.zip [ 12722 ] |
Commented by: @asfernandes alter table test02 alter x drop not null; drops the field's NOT NULL constraint, but the domain's constraint remains. Technically it's still NOT NULL. You will get an error if you try to drop the domain's constraint after it. The updated system trigger is created only in databases created after my change. You cannot control the ODS version of trunk. |
Commented by: @pavel-zotov > Technically it's still NOT NULL. You will get an error if you try to drop the domain's constraint after it. I did not attempt to remove DOMAIN constraint, only field's one was touched. |
Commented by: @asfernandes As I said, there is no error. I resist to put warning because it was always said that nobody checks FB warnings. |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: Done successfully Test Details: Tests that manipulates with NULL fields/domains and check results: |
Submitted by: @pavel-zotov
Attachments:
c4725-fdb-created-20150311-ods12-generation16.zip
WI-T3.0.0.31733
Script:
Output:
X INTEGER Nullable
CONSTRAINT TEST02_PK:
Primary key (X)
============
<null>
<null>
Commits: 5109af2 FirebirdSQL/fbt-repository@7bad9ff
====== Test Details ======
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)
The text was updated successfully, but these errors were encountered: