- Merge request !23Issue #3205682: Primary key not defined for precreate tables β (Closed) created by dpi
- last update
over 1 year ago Composer require-dev failure - π¦πΊAustralia dpi Perth, Australia
Closed π MYSQL READ-COMMITTED For this to work correctly, all tables must have a primary key. Closed: duplicate as a dupe.
- π¦πΊAustralia dpi Perth, Australia
Ideally tests would be great, though a handful of approvals from different orgs would suffice.
My main concern at this point is making sure the proposed changes work on all supported database types (sqlite, postgres, etc).
Will there be no technical problems adding the primary key even existing values? Should we do a check beforehand in case there are invalid (conflicting) rows?
- π¦πΊAustralia acbramley
Hiding patches, let's use the MR please. Needs a rebase against 3.3.x
- Status changed to Needs work
about 1 year ago 4:41am 4 September 2023 - π¨π¦Canada joelpittet Vancouver
Repeating #9 use the MR please. Hiding patches.
- Merge request !35Issue #3205682: Add primary key to occurrence tables β (Merged) created by joelpittet
- last update
about 1 year ago 167 pass - π¨π¦Canada joelpittet Vancouver
First time doing a rebase of an MR, the install file did horrible things so had to move it. Luckily it's relatively small so I hope that does the trick.
- Status changed to Needs review
about 1 year ago 9:02pm 12 October 2023 - π¨π¦Canada joelpittet Vancouver
FYI the patch works to solve the problem. I won't RTBC because I was responsible for the rebase so it would be good to get a second pair of eyes.
- π¨π¦Canada joelpittet Vancouver
@dpi I followed https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... β
Which suggested a new MR for 3.3.x, I'd assume the same is true if it needs 3.5.x and why the MR looks to be failing the pipeline, but I could be wrong? - π¦πΊAustralia dpi Perth, Australia
Hey there, I rebased the work here on major changes to Gitlab testing for this project. These changes were only introduced on the active development branch: 3.5.x. Thusly I changed the base branch from 3.3 to 3.5.
There is a legitimate CS failure.
I just added Postgres and SQLite testing, as I wanted to make sure those engines also work with the changes here. The changes here dont seem to introduce failures, but it did expose that HEAD as is is failing with those engines. It seems on the surface these may only be test only failures.
I'm due to look into those failures before I continue here.
- First commit to issue fork.
- π¦πΊAustralia acbramley
acbramley β changed the visibility of the branch 3205682-primary-key to hidden.
-
dpi β
committed d1c32502 on 3.5.x authored by
joelpittet β
Issue #3205682 by dpi, circuscowboy, SadySierralta, joelpittet,...
-
dpi β
committed d1c32502 on 3.5.x authored by
joelpittet β
- Status changed to Fixed
10 months ago 7:00am 29 January 2024 - π¦πΊAustralia dpi Perth, Australia
Merged.
Changes can be found in
3.5.0-beta1
. Automatically closed - issue fixed for 2 weeks with no activity.
- π΅π±Poland azovsky
I got an ERROR when upgrading from 3.6.0 to 3.7.0 Recurring Dates Field:
date_recur module Update #8208 Failed: Drupal\Core\Database\SchemaObjectExistsException: Cannot add primary key to table 'date_recur__node__field_date_recur': primary key already exists. in Drupal\mysql\Driver\Database\mysql\Schema->addPrimaryKey() (line 513 of /var/www/html/web/core/modules/mysql/src/Driver/Database/mysql/Schema.php).
Any ideas how to fix this? Thank you
- π¦πΊAustralia dpi Perth, Australia
Some people are reporting the primary key already exists for some reason.
I've added further safety in π Add primary key checks before adding them Active