[MCOL-3693] Table CHECK constraint pretends to work but breaks transactional properties Created: 2019-12-25  Updated: 2020-11-09  Resolved: 2020-11-09

Status: Closed
Project: MariaDB ColumnStore
Component/s: N/A
Affects Version/s: 1.4.2
Fix Version/s: 5.5.1

Type: New Feature Priority: Major
Reporter: Elena Stepanova Assignee: Todd Stoffel (Inactive)
Resolution: Fixed Votes: 0
Labels: Compatibility

Issue Links:
Relates
relates to MCOL-935 CHECK Constraints not working for UPDATE Closed
Epic Link: ColumnStore Compatibility Improvements

 Description   

drop table if exists t1;
create table t1 (a int, b int, check(a>b)) engine=Columnstore;
insert into t1 values (1,0),(2,2);
select * from t1;
insert into t1 values (3,0);
select * from t1;

CREATE TABLE above works without any errors or warnings.
First INSERT fails ER_CONSTRAINT_FAILED, so it's not ignored:

MariaDB [db]> insert into t1 values (1,0),(2,2);
ERROR 4025 (23000): CONSTRAINT `CONSTRAINT_1` failed for `db`.`t1`

Following SELECT expectedly returns an empty result set:

MariaDB [db]> select * from t1;
Empty set (0.055 sec)

Next INSERT doesn't break the constraint, so it works.
But after that, the table contains two rows – the last inserted one and also the first one from the previously failed INSERT:

MariaDB f93bfb9288d020b190f5c73a31223fff6439687d

MariaDB [db]> insert into t1 values (3,0);
Query OK, 1 row affected (0.184 sec)
 
MariaDB [db]> select * from t1;
+------+------+
| a    | b    |
+------+------+
|    1 |    0 |
|    3 |    0 |
+------+------+
2 rows in set (0.024 sec)



 Comments   
Comment by Andrew Hutchings (Inactive) [ 2019-12-26 ]

Almost certain this hasn't been implemented for non-MariaDB bulk insert methods and I'm surprised the DDL even parses.

Comment by Elena Stepanova [ 2019-12-26 ]

I would say the main problem here is not that the DDL passes, and not that the check doesn't work, but that it seemingly works at first, and the table is empty after the failed check, but after the second INSERT previously rejected values get pulled out from nowhere.
If the table returned the (1,0) row right after the failed INSERT, it would only be mildly questionable.

Comment by Roman [ 2020-09-30 ]

This is a questionable thing b/c the syntax support simplifies table creation. However I agree that a warning should be made that the CHECK constraint feature works only partially.

Generated at Thu Feb 08 02:44:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.