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

acbramley created an issue. See original summary.

acbramley’s picture

Issue summary: View changes
kwiechmann’s picture

Coincidentally, 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.

raphaeltbm’s picture

Same 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.

acbramley’s picture

Status: Active » Needs review
StatusFileSize
new711 bytes

We 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.

berdir’s picture

Status: Needs review » Needs work

the 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.

acbramley’s picture

Status: Needs work » Needs review
StatusFileSize
new828 bytes

Thanks for that @Berdir, updated with the extra check.

berdir’s picture

Status: Needs review » Fixed

Thanks, committed.

  • Berdir committed b74e1e6 on 8.x-1.x authored by acbramley
    Issue #3076232 by acbramley, kwiechmann, raphaeltbm:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.