You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement composite PRIMARY KEY support at the parser's side and the schema builder
PRIMARY KEY can be found in a couple of positions.
-- Valid Composite PRIMARY KEY Definitions-- 1: Definition as a PRIMARY KEY attributeCREATETABLEusers
(
id INT AUTO_INCREMENT,
name VARCHAR(122) NOT NULL UNIQUE,
profile_id INT,
PRIMARY KEY (id, name)
);
-- 2: Definition as a CONSTRAINT attributeCREATETABLEusers
(
id INT AUTO_INCREMENT,
name VARCHAR(122) NOT NULL UNIQUE,
profile_id INT,
CONSTRAINT PR_User PRIMARY KEY (id, name)
);
ACC:
Simple PRIMARY KEY definitions
1: Definition as a column constraint
2: Definition as a PRIMARY KEY attribute
3: Definition as a CONSTRAINT attribute
Validation rules were adjusted to bypass the composite key(one per table)
PS: it probably makes sense to move keys to a separated child of TableRoot to simplify tree structure & its validation. In this case, the new structure can look like:
Description
Implement composite
PRIMARY KEY
support at the parser's side and the schema builderACC:
PS: it probably makes sense to move keys to a separated child of
TableRoot
to simplify tree structure & its validation. In this case, the new structure can look like:Proposed syntax tree structure:
But this causes inconsistency between other keys and other constraints
The text was updated successfully, but these errors were encountered: