Issue Details (XML | Word | Printable)

Key: CORE-3101
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Dmitry Yemanov
Votes: 3
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Cannot alter the domain after migrating from older versions

Created: 08/Aug/10 10:14 AM   Updated: 14/Feb/11 12:04 PM
Component/s: Engine
Affects Version/s: 2.1.0, 2.5 Alpha 1, 2.1.1, 2.1.2, 2.5 Beta 1, 2.5 Beta 2, 2.1.3, 3.0 Initial, 2.5 RC1, 2.5 RC2, 2.5 RC3
Fix Version/s: 2.5.0, 3.0 Alpha 1

Time Tracking:
Not Specified

Planning Status: Unspecified


 Description  « Hide
Test case:

-- with Firebird 1.5 or 2.0
create domain state smallint;
create table tab (col state, check (col in (0, 1, 2)));
commit;

-- backup / restore

-- with Firebird 2.5
alter domain state set default 0;
commit;

-- ERROR
action cancelled by trigger (1) to preserve data integrity.
Cannot update trigger used by a CHECK Constraint.

The problem is that MET_change_fields() schedules the validation for dependent procedures/triggers. The CHECK constraint has two underlying triggers depending on the domain. During validation, RDB$VALID_BLR is going to be set to TRUE. But its prior value is NULL, as this field didn't exist in ODS 11.0. System trigger RDB$TRIGGER_22 considers that being a meaningful change and throws an exception (its purpose is to disallow modifications of check constraints).

I can think of a few possible solutions:

a) don't validate system triggers (thus not maintaining RDB$VALID_BLR for them)
b) remove comparison for RDB$VALID_BLR from RDB$TRIGGER_22 making this field irrelevant for the check
c) always reset the RDB$VALID_BLR flag during restore (don't preserve its backed up value)


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dimitry Sibiryakov added a comment - 08/Aug/10 12:18 PM - edited
d) Ignore field RDB$VALID_BLR and require all object to be valid on commit (if not - refuse to commit).

Sean Leyne added a comment - 09/Aug/10 12:55 AM
What would the implications be if the source of all triggers where deleted as a "source security" measure by the database admin, on the possible solutions?

Dmitry Yemanov added a comment - 09/Aug/10 05:25 AM
It has nothing to do with the source code. Only BLR is validated.

Sean Leyne added a comment - 09/Aug/10 07:17 PM
Dmitry Y,

Without source how can BLR be "validated"? (Looking for an education on BLR)

Dmitry Yemanov added a comment - 10/Aug/10 04:38 AM
BLR is being parsed and compiled into the internal execution tree format (and probably optimized as well). If any change in the dependencies makes this process to fail for whatever reason, then BLR is considered invalid.