SQL constraint changes #3707

andreyaksenov · 2023-09-12T11:16:17Z

Updated a table constraint syntax to make it more readable and added new testable examples for all constraint types:
https://docs.d.tarantool.io/en/doc/sql-constraint-mechanism/reference/reference_sql/sql_statements_and_clauses/#table-constraint-definition
Added a note about a foreign key's uniqueness checking:
https://docs.d.tarantool.io/en/doc/sql-constraint-mechanism/reference/reference_sql/sql_statements_and_clauses/#table-constraint-definition-for-foreign-keys

ImeevMA

Hi! Thank you for the patch. I have three comments, see them below.

ImeevMA · 2023-09-13T10:20:02Z

doc/reference/reference_sql/sql_statements_and_clauses.rst

-The constraint-name must be an identifier which is valid according to the rules for identifiers.
-The constraint-name must be unique within the table.
+A constraint name must be an identifier that is valid according to the rules for identifiers.
+A constraint name must be unique within the table.


This is not exactly so. There cannot be another table foreign key (= tuple foreign key) constraint with the same name, but it is possible to have a CHECK or UNIQUE table constraint, as well as any column constraint (= field constraint) with the same name.

Changed like this:

A constraint name must be unique within the table for a specific constraint type. For example, the CHECK and FOREIGN KEY constraints can have the same name.

ImeevMA · 2023-09-13T10:26:39Z

doc/reference/reference_sql/sql_statements_and_clauses.rst

+
 Only one column in the table may be autoincrement.
 However, it is legal to say ``PRIMARY KEY (a, b, c AUTOINCREMENT)`` -- in that case, there
 are three columns in the primary key but only the first column (``a``) is AUTOINCREMENT.


I saw this by chance. This is not entirely true. I see that this was added to close #947, but in fact AUTOINCREMENT will be added here to column c.

Thanks, changed to ... but only the third column (``c``) is AUTOINCREMENT.

ImeevMA · 2023-09-13T10:29:36Z

doc/reference/reference_sql/sql_statements_and_clauses.rst

 -   A referenced column has a UNIQUE constraint.
 -   A referenced column has a UNIQUE index.

+Note that before the :doc:`2.11.0 </release/2.11.0>` version, uniqueness of a foreign key is checked when creating a constraint (for example, using ``CREATE TABLE`` or ``ALTER TABLE``).


I think it is more existence of an index on the referenced columns then uniqueness of a foreign key.

Updated to:

Note that before the :doc:`2.11.0 </release/2.11.0>` version, an index existence for the referenced columns is checked when creating a constraint (for example, using ``CREATE TABLE`` or ``ALTER TABLE``). Starting with 2.11.0, this check is weakened and existence of an index is checked during data insertion.

xuniq · 2023-09-13T12:14:16Z

doc/reference/reference_sql/sql_statements_and_clauses.rst

+-   Every table must have one and only one primary key.
+-   Primary-key columns are automatically ``NOT NULL``.
+-   Primary-key columns are automatically indexed.
+-   Primary-key columns are unique, that is, it is illegal to have two rows that have the same values for the columns specified in the constraint.


Suggested change

- Primary-key columns are unique, that is, it is illegal to have two rows that have the same values for the columns specified in the constraint.

- Primary-key columns are unique. That means it is illegal to have two rows with the same values for the columns specified in the constraint.

xuniq · 2023-09-13T12:32:46Z

doc/reference/reference_sql/sql_statements_and_clauses.rst


 There is a shorthand: specifying UNIQUE in a :ref:`column definition <sql_column_def_constraint>`.

 Unique constraints are similar to primary-key constraints, except that:


Suggested change

Unique constraints are similar to primary-key constraints, except that:

* Unique constraints are similar to primary-key constraints, except that:

a table may have any number of unique keys, and unique keys are not automatically ``NOT NULL``.

* Unique columns are automatically indexed.

* Unique columns are unique. That means it is illegal to have two rows with the same values in the unique-key columns.

Let's make the formatting consistent

xuniq · 2023-09-13T12:36:57Z

doc/reference/reference_sql/sql_statements_and_clauses.rst

 -   A referenced column has a UNIQUE index.

+Note that before the :doc:`2.11.0 </release/2.11.0>` version, an index existence for the referenced columns is checked when creating a constraint (for example, using ``CREATE TABLE`` or ``ALTER TABLE``).
+Starting with 2.11.0, this check is weakened and existence of an index is checked during data insertion.


Suggested change

Starting with 2.11.0, this check is weakened and existence of an index is checked during data insertion.

Starting with 2.11.0, this check is weakened and the existence of an index is checked during data insertion.

xuniq · 2023-09-13T13:14:34Z

doc/reference/reference_sql/sql_statements_and_clauses.rst


-UNIQUE constraints look like this: |br|
-:samp:`UNIQUE ({column-name} [, {column-name}...])`
+UNIQUE constraints look like this:


Suggested change

UNIQUE constraints look like this:

**UNIQUE constraints**

UNIQUE constraints look like this:

I think it's necessary to separate the paragraphs about PRIMARY | UNIQUE | CHECK constraints from each other somehow (with bold?). It's a bit difficult to figure out where a new paragraph starts.

Agree, will do

andreyaksenov force-pushed the sql-constraint-mechanism branch 2 times, most recently from 4018db5 to 2ed6dc5 Compare September 12, 2023 12:13

andreyaksenov linked an issue Sep 12, 2023 that may be closed by this pull request

SQL: changes in using the constraint mechanism #3246

Closed

andreyaksenov force-pushed the sql-constraint-mechanism branch 3 times, most recently from 80394ee to c300746 Compare September 12, 2023 14:24

andreyaksenov linked an issue Sep 12, 2023 that may be closed by this pull request

feedback: SQL statements and clauses | Tarantool #3703

Closed

andreyaksenov force-pushed the sql-constraint-mechanism branch 3 times, most recently from 86da5f3 to b4316c3 Compare September 13, 2023 08:50

andreyaksenov requested a review from ImeevMA September 13, 2023 10:06

ImeevMA reviewed Sep 13, 2023

View reviewed changes

andreyaksenov force-pushed the sql-constraint-mechanism branch from b4316c3 to 6b55382 Compare September 13, 2023 11:36

xuniq self-requested a review September 13, 2023 11:54

xuniq reviewed Sep 13, 2023

View reviewed changes

SQL constraint changes

c042ab0

andreyaksenov force-pushed the sql-constraint-mechanism branch from 6b55382 to c042ab0 Compare September 13, 2023 13:23

xuniq approved these changes Sep 14, 2023

View reviewed changes

andreyaksenov merged commit 5272887 into latest Sep 14, 2023

andreyaksenov deleted the sql-constraint-mechanism branch September 14, 2023 07:01

	- Primary-key columns are unique, that is, it is illegal to have two rows that have the same values for the columns specified in the constraint.
	- Primary-key columns are unique. That means it is illegal to have two rows with the same values for the columns specified in the constraint.


		There is a shorthand: specifying UNIQUE in a :ref:`column definition <sql_column_def_constraint>`.

		Unique constraints are similar to primary-key constraints, except that:

-Unique constraints are similar to primary-key constraints, except that:
+*   Unique constraints are similar to primary-key constraints, except that:
+    a table may have any number of unique keys, and unique keys are not automatically ``NOT NULL``.
+*    Unique columns are automatically indexed.
+*   Unique columns are unique. That means it is illegal to have two rows with the same values in the unique-key columns.

	Starting with 2.11.0, this check is weakened and existence of an index is checked during data insertion.
	Starting with 2.11.0, this check is weakened and the existence of an index is checked during data insertion.

SQL constraint changes #3707

SQL constraint changes #3707

Uh oh!

Conversation

andreyaksenov commented Sep 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ImeevMA left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

andreyaksenov commented Sep 12, 2023 •

edited

Loading