MDEV-21181 Add Support for Generated Invisible Primary Keys#4718
MDEV-21181 Add Support for Generated Invisible Primary Keys#4718jaeheonshim wants to merge 1 commit intoMariaDB:mainfrom
Conversation
|
|
gkodinov
added
the
External Contribution
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contributions. This is a preliminary review.
Couple of things to fix:
- please squash your changes into a single commit and add a commit message that follows CODING_STANDARDS.md
- please make sure the tests are passing. There's one test to re-record and one to fix.
jaeheonshim
force-pushed
the
MDEV-21181
branch
2 times, most recently
from
829e2a2 to
ebe9abd
Compare
| return 0; | ||
| } | ||
|
|
||
| static bool is_auto_pk_field(Field *field) |
There was a problem hiding this comment.
I'd also check if the name. Not 100 fool-prof vs me doing:
CREATE TABLE t1 (_inv_PK SERIAL INVISIBLE PRIMARY KEY, c2 INT) ENGINE=InnoDB;
then the next ALTER TABLE dropping my manually defined primary key, i.e.
ALTER TABLE t1 ADD uniq_1 PRIMARY KEY;
But still better than nothing.
Please add a test case for this and have it documented in the MDEV that even explicitly created primary keys will be replaced in this case!
There was a problem hiding this comment.
Hi Georgi, I can definitely implement a prefix name check for improved robustness (the column name can be _inv_PK1, etc. if there is a collision). However, just wanted to mention that I don't think the case you are describing is an issue, as in order for _inv_PK to be detected as an autogenerated primary key and dropped during an ALTER TABLE operation, its column must be marked as INVISIBLE_FULL, and the key must be marked as generated, both of which are not possible on the user's end.
There was a problem hiding this comment.
That's not really true from what I read in the code.
You're indeed marking the key as generated when you add it.
BUT, on ALTER, when you are trying to find an existing key to replace if an explicit PR or unique key is specified by the user, you do not check the generated flag.
So, I still think it's a good idea to check the name.
jaeheonshim
force-pushed
the
MDEV-21181
branch
4 times, most recently
from
1e86494 to
1139a1d
Compare
This PR implements a new session/global option `sql_generate_invisible_primary_key`. When this option is on, MariaDB will automatically generate an invisible primary key for tables created without an explicit primary key. The type of the auto-generated primary key is `BIGINT UNSIGNED AUTO_INCREMENT`. If an ALTER TABLE ADD PRIMARY KEY statement is executed on a table with an generated primary key, the generated primary key will be silently dropped. Notes: - Internally, the generated primary key has the INVISIBLE_FULL attribute. This means that the key and column effectively do not exist to the user and will not appear in SHOW CREATE TABLE and SHOW COLUMNS. Furthermore, the user cannot explicitly drop the generated primary key. - The column name of the invisible generated primary key is _inv_PK. If the user creates their own column named _inv_PK, the generated primary key column's name will be suffixed with a number. - If the storage engine does not support auto increment, no generated primary key will be added.
| return 0; | ||
| } | ||
|
|
||
| static bool is_auto_pk_field(Field *field) |
There was a problem hiding this comment.
That's not really true from what I read in the code.
You're indeed marking the key as generated when you add it.
BUT, on ALTER, when you are trying to find an existing key to replace if an explicit PR or unique key is specified by the user, you do not check the generated flag.
So, I still think it's a good idea to check the name.
3 participants
Jira: MDEV-21181
This PR implements a new session/global option
sql_generate_invisible_primary_key. When this option is ON, MariaDB will automatically generate an invisible primary key for tables created without an explicit primary key.The type of the auto-generated primary key is
BIGINT UNSIGNED AUTO_INCREMENT. The primary key has theINVISIBLE_FULLattribute, meaning that to the user, it effectively does not exist and it is hidden fromSHOW CREATE TABLEandSHOW COLUMNS. Furthermore, the user cannot explicitly drop the auto-generated primary key. However, if the user later adds their own primary key, the generated PK field and key are dropped.Internally, the name of the generated primary key is
_inv_PK, but this does not prevent the user from creating or adding their own column named_inv_PK. In that case, the generated primary key will be suffixed with a number (e.g._inv_PK1,_inv_PK2, etc.).