Problem/Motivation
As discussed in #3068310: Composite primary key with specified index length fails the NOT NULL check, limited length keys are applicable only to indexes, not to primary and unique keys.
See #11 there:
A fundamental/conceptual question here: are we sure we want to support partial lenght columns in a unique key context here (primary/unique keys)? IMHO it seems weird you design a table with fields that you want to be kind of unique via PK, then to have a PK that would fatally fail when trying to insert records that lead to duplicate key, which can happen if your field varies in the part that is not part of the key -- how are we going to decide which is the 'right' key and record?
Recently, Doctrine DBAL have introduced partial length support to indexes https://github.com/doctrine/dbal/pull/2412, but have done so only for indexes, that allow duplicated keys - not for primary/unique keys.
Proposed resolution
- Deprecate createion of PKs or unique keys with limited length in 10.2 then throw a
SchemaExceptionor similar in 11. - Update database API docs accordingly.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3082239
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cilefen commentedComment #8
mondrakeworking on this
Comment #9
daffie commented@mondrake: I cannot find any support for this in the PostgreSQL and the SQLite documentation. AFAIK Doctrine DBAL only supports this on MySQL.
Comment #10
mondrake@daffie I think here we should not look at what databases allow or not, but take a decision on what we want to support in Drupal: do we allow partial length for the columns in unique key (unique/primary) contexts, or not?
BTW - I have serious doubts that trying to specify a primary key with partial column length works at all in HEAD right now. It's not tested, though. Here we'd be simply certifying that and adding the testing.
Comment #11
mondrakeA test only patch to check #10 re. what happens specifying a primary key with partial column length in HEAD on all the dbs.
Comment #12
mondrakeComment #13
mondrakeReady for review.
With this patch, we clean up the situation a bit.
SchemaExceptionSchema::createTable(),Schema::addPrimaryKey(),Schema::addUniqueKey(),Schema::addField(),Schema::changeField()Schema::ensureNotNullPrimaryKey()in favour of a more genericSchema::validatePrimaryKeySchema()methodThis needs a CR and its number to be reflected in the MR.
Comment #14
mondrakeComment #15
mondrakeBTW - there are no cases of partial length primary/unique keys in core HEAD at the moment, so this is entirely related to clarifying the status on behalf of contrib.
Comment #18
mondrakeComment #19
mondrakerebased
Comment #20
mondrakeComment #22
mondrakeRebased and adjusted
Comment #23
smustgrave commentedWonder if the title/issue summary could be updated. Since it's applying to more then documents. Also see it was tagged for a CR if that could happen too please.
Comment #24
mondrakeTrying to make issue title and summary clearer.
Agreed this is not a Documentation only issue, removed tag - docs need update because these changes are applied.
Working on CR and patch update.
Comment #25
mondrakeComment #26
mondrakeAdded a draft CR, https://www.drupal.org/node/3375071
Comment #27
smustgrave commentedThanks @mondrake! Much clearer.
Wasn't entirely sure how to test so I did something similar to testInvalidPrimaryKeyColumnsOnCreateTable and your CR and created a table with a a primary key of 10. And got the exception as expected.
The CR was clear of the change and included great examples.
Think this is ready for committers to take a look.
Comment #28
catchMostly looks good but a handful of comments on the MR.
Comment #29
mondrakeReplied inline and adjusted the deprecation messages.
Comment #30
smustgrave commentedlets find out!
Comment #31
catchI'm pretty sure it won't, so we should either duplicate the documentation, or add @see in the relevant places, and/or file an api.drupal.org issue to support it.
Comment #32
mondrakeFiled #3376270: Support PHPStan's annotations for local type aliases and array shapes in the API module issue queue - if in the future we want to use PHPStan to higher levels we can't be stopped by that, so better request a change there now.
Comment #33
andypostTests for index limits for pgsql/sqlite requested in #3389202-10: migrate\Plugin\migrate\id_map\Sql assumes a PDO db driver
Comment #34
mondrake@fjgarlin I commented inline - can you please elaborate the suggestion?
Comment #35
mondrakeComment #36
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #37
mondrakeComment #38
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #39
mondrakeComment #40
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #41
mondrakeComment #42
mondrake#3411490: Replace array-based DB Schema API with a value object structure and #3558426: Add property validation for SchemaDefinition value objects would make most of this duplicate.
Comment #44
smustgrave commented@daffie curious your thoughts on the MR?
Comment #45
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #46
mondrakeComment #47
smustgrave commentedWanted to follow up on this one if any of the previous reviewers had a look at the latest changes?
Comment #48
daffie commentedAll the code changes look good to me.
The required tests have been added.
The IS and the CR are in order.
For me it is RTBC.
Comment #49
quietone commentedAll the deprecation messages state 11.3.0, so they need to be changed.
Comment #50
quietone commentedForgot to add that I updated credit.
Also, the change record is out of date.
Comment #51
mondrake#49 and #50 done. Hopefully for the last time, the original CR was prepared for 10.2.