Let me preface this by saying that I have no idea *why* this problem happens, or why the patch fixes it.
I came across this while updating Lightning to use the latest beta of Multiversion. Lightning Preview comes with Replication as well. Multiversion's updates ran without trouble (after patching it with #2865404: Update #8007 wrongly assumes that all enabled entity types have a revision table), but then I ran into errors while publishing my Stage workspace:
Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'session_id' in 'field list': INSERT INTO {replication_log_revision} (id, session_id, source_last_seq, ok, _deleted, _rev) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array
I traced through this and discovered that, somehow, the replication_log_revision database table did not contain columns for most of the base fields, including session_id.
Somehow, adding a revision_data_table key to the ReplicationLog entity type definition before running Multiversion's updates fixes the problem -- after the updates, replication_log_revision has all the proper columns. Why does this work? No idea. But here is a patch for those who might run into this weirdness.
Comment | File | Size | Author |
---|---|---|---|
#4 | interdiff.txt | 1.38 KB | jeqq |
#4 | 2865818-4.patch | 6.38 KB | jeqq |
| |||
#3 | 2865818-3.patch | 6.43 KB | jeqq |
| |||
#2 | 2865818-2.patch | 700 bytes | phenaproxima |
|
Comments
Comment #2
phenaproximaComment #3
jeqq@phenaproxima Thanks for reporting and debugging this. I've tried to reproduce it and seems that the patch from #2 doesn't fix the problem. We also have the case when the update hook from Multiversion might be executed before applying that patch. A better solution I think is to make those fields revisionable and implement an update hook for Replication.
Comment #4
jeqqSome fixes.
Comment #6
jeqq