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

Broken foreign key handling for multi-segmented index using multi-level collations [CORE1997] #2434

Closed
firebird-issue-importer opened this issue Jul 16, 2008 · 10 comments

Comments

@firebird-issue-importer

Submitted by: @asfernandes

Is related to QA474

Using multilevel collations in a key with more than one field, FB uses interleaved keys.

For a key with fields (a, b):
- full key: <level 1 for a>...<level n for a><level 1 for b>...<level n for b>
- unique key for non-insensitive collations: same as full key
- unique key for insensitive collations, may use less number of levels: <level 1 for a><level 1 for b>

This doesn't cause any problem in these conditions:
- Non insensitive collations that compares strings as if it's comparing the keys
- Insensitive collations used in unique index, as the unique key is used there

For non-unique index (see TEXTTYPE_SEPARATE_UNIQUE in intlobj_new.h), the optimizer handle (or try :-)) the situation for index walking more or less as following:
a = 'x' and b = 'y' => a starting with 'x'

For handling the non-unique side of a foreign key (when deleting/modifying the unique/primary side), the same code should be used there. But this code is using BTR_key which generate keys different than BTR_make_key (used in index walk) and doesn't consider the lower/upper retrieval attributes.

Test case:

create table pk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
primary key (c1, c2)
);

create table fk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
foreign key (c1, c2) references pk
);

insert into pk values ('a', 'b');
insert into fk values ('A', 'b');

delete from pk; -- should not be allowed

select * from fk;

Commits: d16fad4 c3709b3 FirebirdSQL/fbt-repository@00fee42

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 16, 2008

Modified by: @asfernandes

description: Using multilevel collations in a key with more than one field, FB uses interleaved keys.

For a key with fields (a, b):
- full key: <level 1 for a>...<level n for a><level 1 for b>...<level n for b>
- unique key for non-insensitive collations: same as full key
- unique key for insensitive collations, may use less number of levels: <level 1 for a><level 1 for b>

This doesn't cause any problem in these conditions:
- Non insensitive collations that compares strings as if it's comparing the keys
- Insensitive collations used in unique index, as the unique key is used there

For non-unique index (see TEXTTYPE_SEPARATE_UNIQUE in intlobj_new.h), the optimizer handle (or try :-)) the situation for

index walking more or less as following:
a = 'x' and b = 'y' => a starting with 'x'

For handling the non-unique side of a foreign key (when deleting/modifying the unique/primary side), the same code should

be used there. But this code is using BTR_key which generate keys different than BTR_make_key (used in index walk) and

doesn't consider the lower/upper retrieval attributes.

Test case:

create table pk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
primary key (c1, c2)
);

create table fk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
foreign key (c1, c2) references pk
);

insert into pk values ('a', 'b');
insert into fk values ('A', 'b');

delete from pk; -- should not be allowed

select * from fk;

=>

Using multilevel collations in a key with more than one field, FB uses interleaved keys.

For a key with fields (a, b):
- full key: <level 1 for a>...<level n for a><level 1 for b>...<level n for b>
- unique key for non-insensitive collations: same as full key
- unique key for insensitive collations, may use less number of levels: <level 1 for a><level 1 for b>

This doesn't cause any problem in these conditions:
- Non insensitive collations that compares strings as if it's comparing the keys
- Insensitive collations used in unique index, as the unique key is used there

For non-unique index (see TEXTTYPE_SEPARATE_UNIQUE in intlobj_new.h), the optimizer handle (or try :-)) the situation for index walking more or less as following:
a = 'x' and b = 'y' => a starting with 'x'

For handling the non-unique side of a foreign key (when deleting/modifying the unique/primary side), the same code should be used there. But this code is using BTR_key which generate keys different than BTR_make_key (used in index walk) and doesn't consider the lower/upper retrieval attributes.

Test case:

create table pk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
primary key (c1, c2)
);

create table fk (
c1 varchar (5) character set utf8 collate unicode_ci,
c2 varchar (5) character set utf8 collate unicode_ci,
foreign key (c1, c2) references pk
);

insert into pk values ('a', 'b');
insert into fk values ('A', 'b');

delete from pk; -- should not be allowed

select * from fk;

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 12, 2012

Modified by: @asfernandes

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 12, 2012

Modified by: @asfernandes

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

resolution: Fixed [ 1 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 13, 2012

Commented by: Attila Molnár (e_pluribus_unum)

It seems similar to CORE3052. Are they related?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 13, 2012

Commented by: @asfernandes

> It seems similar to CORE3052. Are they related?

No.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Feb 27, 2012

Modified by: @asfernandes

Fix Version: 2.5.2 [ 10450 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 27, 2014

Modified by: @pcisar

Link: This issue is related to QA474 [ QA474 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 7, 2014

Modified by: @pmakowski

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test => Done successfully

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