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

Jump to bottom

Recalculating computed fields that depend on altering field [CORE5633] #5899

Open
firebird-automations opened this issue Oct 9, 2017 · 6 comments
Open

Recalculating computed fields that depend on altering field [CORE5633] #5899

firebird-automations opened this issue Oct 9, 2017 · 6 comments
Labels
affect-version: 2.5.6 affect-version: 2.5.7 affect-version: 3.0.0 affect-version: 3.0.1 affect-version: 3.0.2 affect-version: 4.0 Alpha 1 component: engine priority: major type: bug

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @vasiliy-yashkov

When field is altered, a computed fields, that depend on it, don't altered.
Example:
create table test(f1 varchar(6));
commit;
create table test1(f1 integer, f2 computed by((select first 1 f1 from test)));
commit;
alter table test alter column f1 type varchar(8);
commit;
insert into test(f1) values('qwertyqw');
commit;
insert into test1(f1) values(1);
commit;
select * from test1; --arithmetic exception, numeric overflow, or string truncation
@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

What if F2 had a explicit type? It shouldn't change automatically.

@firebird-automations
Copy link
Collaborator Author

Commented by: @vasiliy-yashkov

There are ways to handle this error? Or leave as is? Maybe don't allow to alter field if there are dependent on it?

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

this is realy crazy to allow computed by dependend on select..

what next?
CREATE ASCENDING INDEX IXAE_TEST1__F2 ON test1 COMPUTED BY(F2);

how this index can work then properly?

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

@Karol,

I agree, just because a DBA has the ability to define a computed field does not mean that every possible consideration can be supported, as is clearly the case in this example.

@vasiliy,

What is the purpose of the CREATE VIEW, in the example?

@firebird-automations
Copy link
Collaborator Author

Commented by: @vasiliy-yashkov

@sean,

It's unnecessary part, sorry.

@Karol,

Ok, bad example, but only to indicate a problem.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

description: When field is altered, a computed fields, that depend on it, don't altered.
Example:
create table test(f1 varchar(6));
commit;
create table test1(f1 integer, f2 computed by((select first 1 f1 from test)));
commit;
create view v1 as select f1 from test;
commit;
alter table test alter column f1 type varchar(8);
commit;
insert into test(f1) values('qwertyqw');
commit;
insert into test1(f1) values(1);
commit;
select * from test1; --arithmetic exception, numeric overflow, or string truncation

=>

When field is altered, a computed fields, that depend on it, don't altered.
Example:
create table test(f1 varchar(6));
commit;
create table test1(f1 integer, f2 computed by((select first 1 f1 from test)));
commit;
alter table test alter column f1 type varchar(8);
commit;
insert into test(f1) values('qwertyqw');
commit;
insert into test1(f1) values(1);
commit;
select * from test1; --arithmetic exception, numeric overflow, or string truncation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
affect-version: 2.5.6 affect-version: 2.5.7 affect-version: 3.0.0 affect-version: 3.0.1 affect-version: 3.0.2 affect-version: 4.0 Alpha 1 component: engine priority: major type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@firebird-automations