Primary keys missing

Hi @mizage@gmail.com ,
I have fixed this issue "Primary keys missing" and also created MR,
kindly review the MR.

I reviewed the MR. On the publishing_options_bundles table the better primary key option would on the pubid as it does for the publishing_options table. Updated the MR, please review

Updated the MR with hook_update that tested locally. Note that if you applied https://git.drupalcode.org/project/pub_options/-/merge_requests/15/diffs... already, it wont have any effects. Or you have to revert it to the earlier and run drush updb.

Hi and thanks for the update. I'll check the code and get it merged in once I'm done testing!

Thanks @geocalleo. When i tried to apply the patch from MR via composer (https://git.drupalcode.org/project/pub_options/-/merge_requests/17.patch) it fails (As there are conflicts in publishing_options.install). I had to wget the patch to local and then git apply -3 patch and had to resolve the conflict to get it work. I think all other changes was already there in place for 2.0.3 version.

Hi @MukhtarM, I am trying to merge the updates you put in place. But it looks like the merge request is set for 2.x branch. Can you switch that over to 2.0.0 branch? I've been making release tags on that branch for the latest releases.

Yea sure @geocalleo i will do that

@geocalleo i raised against 2.0.0 now. First i tried to raise in the git UI itself (as there no code change), but it didn't worked. Thats why there is a intermediate MR :)

None of those branches/pr could be applied on 2.0.3 what should be the steps?
Do we have a patch that can be applied?

thread started: 2026-10-03 - - current comment added: 2026-06-21 -

Drupal 11 admin [ status report] error:

Transaction isolation level
READ-COMMITTED
For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: captcha_questions_dblog. See the setting MySQL transaction isolation level page for more information.

The - captcha_questions_dblog - table needs a primary key.

Hi all,

Thanks for the report, @mlcage, and thanks @sarwan_verma and @mukharrm for taking a crack at this.

I committed a fix to the 2.0.x branch (6b17b72) and tagged it as 2.0.4. I went a slightly different route from the MRs, so here's the quick rundown:

The two tables are many-to-many. One publishing option can map to a bunch of bundles, and a node can have more than one option on it, so the keys need to be composite instead of single column: publishing_options_bundles gets (pubid, bundle) and publishing_options_option_node gets (pubid, nid). I left pubid as a plain int since it's just pointing back at publishing_options, not a serial.

For existing sites, the update hook (publishing_options_update_8001) clears out any duplicate rows first and then adds the keys, so you just need to run your db updates after pulling 2.0.4. I bumped it to 8001 since update hooks numbered below 8000 don't actually run on Drupal 8+.

I tested it on a Drupal 10 site set to READ COMMITTED. Before the update the status report flags both tables, and once it runs the isolation check goes back to green. Fresh installs come out with the keys already in place.

Marking this fixed. Thanks again, everyone.