Problem/Motivation
I'm trying to upgrade from paragraphs 8.x-1.6 to 1.9 and getting the following error due to the fact my entity type doesn't have (and seemingly doesn't need) a revision_data_table. The entity type only contains a single cardinality, revisionable entity reference field, and a multi cardinality ERR field.
Because of this, getRevisionDataTable returns NULL and the query blows up as seen below.
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'local.f' doesn't exist: SELECT f.id AS id, f.content_target_revision_id AS content_target_revision_id
FROM
{} f
INNER JOIN {paragraphs_item_revision_field_data} p ON f.content_target_revision_id = p.revision_id
WHERE (((p.parent_id <> f.id)) OR (p.parent_type <> :db_condition_placeholder_0) OR (p.parent_field_name <> :db_condition_placeholder_1)) AND ((p.langcode = f.langcode))
ORDER BY p.revision_id ASC
LIMIT 100 OFFSET 0; Array
(
[:db_condition_placeholder_0] => personalised_variant
[:db_condition_placeholder_1] => content
)
[error] Update failed: paragraphs_post_update_rebuild_parent_fields
Proposed resolution
Not too sure...
Comments
Comment #2
acbramley commentedComment #3
kwiechmann commentedCoincidentally, I ran across a similar problem when going from 1.5 to 1.9 and uploaded a patch. This may get you a littler further ahead. Looking for comments and recommendations by others more familiar with this module.
Comment #4
raphaeltbm commentedSame here, i've added some extra condition to your patch, as i running in an issue where a revision field is returned but still doesn't exist in DB.
Comment #5
acbramley commentedWe can't just skip tables for entity types that don't have revision data tables, instead this seems to fix it for me. What happens here, is if the field cardinality is 1 then there would have to be a revision data table, otherwise it'll be stored in a separate table even for the base field definition (which is what I'm getting). E.g I have the following tables:
personalised_variant
personalised_variant__content
personalised_variant_revision
personalised_variant_revision__content
This patch fixes the issue and correctly selects from personalised_variant_revision__content
EDIT: This still might not cover everything, I just quickly tested adding a new entity type identical to mine except made the ERR field a revisionable, single cardinality field and it still didn't create a revision data table. Instead everything was just stored in the revision table.
Comment #6
berdirthe revision data table isn't related to cardinality, it's related to translatable or not.
So what we need is to check for three conditions, if cardinality == 1 and base field, inner condition: if translatable, use revision data table, if not, use revision table. Possibly just a getRevisionDataTabl() ?: getRevisionTable() should also be fine.
Comment #7
acbramley commentedThanks for that @Berdir, updated with the extra check.
Comment #8
berdirThanks, committed.