Subject | [ib-support] Metadata changes and some related questions |
---|---|
Author | Dmitry Yemanov |
Post date | 2001-07-04T08:37:06Z |
Hi,
As far as I understand, a DDL statement to create a table is executed in the
following order (please correct me if I'm wrong here):
1. DDL is translated to DML on system tables
2. DML is executed and necessary rows are added to rdb$relations,
rdb$relation_fields, etc.
3. When the txn is commited, data pages for this table are allocated in the
database file(s)
This causes some questions to be raised:
1. If I create the table twice in the same txn, I get an error for the
second statement that the table already exists. As for me, it is right and
metadata should be protected from redeclaration. But the trick is that it
exists partially (only in the system tables) and it causes a bit illogical
behaviour - if I get the "already exists" error and rollback the txn, then I
can see that the table *doesn't exist*. Or if the second statement is select
one, I get the "table unknown" error. Ambiguously enough, huh?
2. More interesting situation occurs when I alter a table and update its
rows in the same txn (in one script, for example). The engine allows the
update statement to be executed, but after the commit the data may possibly
become corrupted. I have tested this situation with the code like this:
ALTER TABLE TEST
ADD NEW_FIELD SMALLINT NOT NULL DEFAULT 0;
UPDATE TEST
SET NEW_FIELD = 1;
COMMIT;
and got NEW_FIELD equal to 0 and OLD_FIELD (existing column declared as
VARCHAR(30)) equal to '1' !!!!!
Any comments? Yes, I know the DDL and DML should not be mixed in the same
txn, but anyway... just wondering...
Cheers,
Dmitry
As far as I understand, a DDL statement to create a table is executed in the
following order (please correct me if I'm wrong here):
1. DDL is translated to DML on system tables
2. DML is executed and necessary rows are added to rdb$relations,
rdb$relation_fields, etc.
3. When the txn is commited, data pages for this table are allocated in the
database file(s)
This causes some questions to be raised:
1. If I create the table twice in the same txn, I get an error for the
second statement that the table already exists. As for me, it is right and
metadata should be protected from redeclaration. But the trick is that it
exists partially (only in the system tables) and it causes a bit illogical
behaviour - if I get the "already exists" error and rollback the txn, then I
can see that the table *doesn't exist*. Or if the second statement is select
one, I get the "table unknown" error. Ambiguously enough, huh?
2. More interesting situation occurs when I alter a table and update its
rows in the same txn (in one script, for example). The engine allows the
update statement to be executed, but after the commit the data may possibly
become corrupted. I have tested this situation with the code like this:
ALTER TABLE TEST
ADD NEW_FIELD SMALLINT NOT NULL DEFAULT 0;
UPDATE TEST
SET NEW_FIELD = 1;
COMMIT;
and got NEW_FIELD equal to 0 and OLD_FIELD (existing column declared as
VARCHAR(30)) equal to '1' !!!!!
Any comments? Yes, I know the DDL and DML should not be mixed in the same
txn, but anyway... just wondering...
Cheers,
Dmitry