Update viewsreference_update_8103 fails if table name is too long and shortened by Drupal

That might be Drupal\Core\Entity\Sql\DefaultTableMapping::generateFieldTableName(). Could you maybe test this and provide a patch?

You should probably try Drupal\Core\Entity\Sql\DefaultTableMapping::getDedicatedDataTableName() and/or Drupal\Core\Entity\Sql\DefaultTableMapping::getDedicatedRevisionTableName().

I've taken a stab at a patch for this. Works in my Drupal 8.5.1 environment.

Last patch file was incorrectly formatted. Please use this one instead.

There were still some issues in the last patch. Adding back in the calls to the entity update manager.

Should I apply the last patch if I already applied the previous one with composer? Or should I remove it first (how)?
UPD: repatched.

The code for this is pretty complex, so it would really help of more people could test the patch and confirms it solves the issue!

thanks, patch save me a lot of time for upgrading!

Patch works as intended . Thanks a lot

I do not want create a new issue for this small changes. The migration process overrides existing data, with this changes we merge title/argument into data.

oh the patch from #7 contains a PATCHES.txt ;-)

#13 let the update process go through.

But all of existing views reference paragraph data is gone with it.

I will work on a test for this db upgrade thing.

This patch worked great! I just updated to the 2.0 version of this module, because I needed to update in preparations for jumping up to D9.
I totally hit the base table not found error during database updates, but with this patch, I no longer get the errors during updb, and fields using views references appear to be working just fine and didn't notice any issues.

I'm not sure about #14, because in my case, the views reference data is maintained during the upgrade and all is seemingly working fine.

The update hook test did not work locally, because of a undefined bundles key in $field_map, but perhaps here. :D

Tests are not enabled? We are lost. :D

Fixed the undefined bundles key. (\Drupal\Core\Entity\EntityFieldManagerInterface::getFieldMapByFieldType)

Added config schema for successfully test. #2957529: Implement configuration schema for Views reference field storage+settings and widget+formatter

I was also successful with #13. Before running DB updates, I made a copy of the one paragraph field table. After the DB update, I was able to export the table and import back in, and the structure was intact. I was a little confused at first that this particular field didn't also have a revisions table, but I guess that is not necessary for this type of field.

#20 worked for me, though I still did get one warning in the update:

Invalid argument supplied for foreach() better_exposed_filters.install:24

Following up because I had issues with #20 where the supplied schema caused the "enabled settings" to fail to save properly. The values should be strings for them, currently only Pagination and Arguments will work otherwise. These settings are simple key/value pairs for the setting names and not their stored data (ie the number of items to show for "limit").

Is this, b/tests/fixtures/update/drupal-8.9.6.viewsreference-8.x-1.4.php.gz, needed from the last patch in #20

@SocialNicheGuru

For the test yes.

I have this problem and patch #20 allowed the database update to succeed where before it was failing.

I'm not sure if this is an issue related to this patch or if this is a separate issue, but I am getting these warnings now when saving a node with a views reference field (although the node and field data is saved correctly)...

Warning: Undefined array key "data" in Drupal\viewsreference\Plugin\Field\FieldType\ViewsReferenceItem->setValue() (line 97 of modules/contrib/viewsreference/src/Plugin/Field/FieldType/ViewsReferenceItem.php).
Deprecated function: unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in Drupal\viewsreference\Plugin\Field\FieldType\ViewsReferenceItem->setValue() (line 97 of modules/contrib/viewsreference/src/Plugin/Field/FieldType/ViewsReferenceItem.php).

Yay, got the tests to run. Thanks so much for the work on this. It would be great to get this in, I think this is the most important stable blocker at the moment.

Here is a first update simply fixing the PHPCS errors in #20.

Locally I'm getting a different error than DrupalCI:

There should be no errors in configuration 'core.entity_view_display.node.page.default'. Errors:
Schema key core.entity_view_display.node.page.default:content.field_viewsreference.settings.plugin_types.default failed with: variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData
Schema key core.entity_view_display.node.page.default:content.field_viewsreference.settings.plugin_types.page failed with: variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData
Schema key core.entity_view_display.node.page.default:content.field_viewsreference.settings.plugin_types.feed failed with: variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData

Don't have the time to dig deeper at the moment, but hopefully, someone else can continue now we have the tests running!

Data can be empty (NULL) therefore I added a check and defaulted the value to empty array.

Also I created a new dump with 2 revision.

+ Some more asserts.

To test the scope I added also a field to a term.

test only patch.

Lets skip the test for D10.

Coding standards.

On a _quick_ passthrough of this code I noticed that the ${var} syntax is being used in strings. PHP 8.2 doesn't like that ;)

Perhaps consider using sprintf to prepare the table/column names?

Hi, could you give a solution for this in code please? Thanks!

Great job on the tests, thanks! I think it would be nice to fix #38 as well. After that, it would really help to a bit more people to test this. But since this is a stable blocker I would really like to get this in asap.

#37 worked for me. Here's an updated version that addresses #38 by changing "${field_name}_..." to "{$field_name}_...".

+1 RTBC for patch #41

Sharing that the patch at #41 has worked here too. Thanks so much for the push!

Finally got around to commit it. Thanks everyone for your hard work! ❤️
This is a great step towards getting 2.x stable!

We forgot to include removing all unchecked viewsreference "plugin_types", "preselect_views" and "enabled_settings" field settings.

Before this patch, we had no schema definition for "plugin_types", "preselect_views" and "enabled_settings" AND no fieldSettingsFormValidate() method, which simply removes all unchecked setting values before form submission. So the module used to save both unchecked and checked field settings in config. If the value was checked, it saved the name of the value as a string (e.g. page:page) or if it was uncheckd as "0" (e.g. page: 0).

After this patch, the empty values are not getting saved anymore, but they still exist in config if not manually resaved. And since "viewsreference.plugin_types" and "preselect_views" (also "enabled_settings" now through #3402036: Configuration schema for "Enable extra settings" (title,pagination,...) incorrect), are defined as sequences of strings, but the old implicit schema definition for an unchecked value was integer, the following error will appear using config_inspector:

variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData

Here is an exported config as an example, showing the old unchecked values still saved:

  plugin_types:
    default: default
    page: page
    block: block
    attachment: attachment
    feed: feed
    entity_browser: 0
  preselect_views:
    admin_header_slides: 0
    block_content: 0
    content: 0
    content_recent: 0
    files: 0
    frontpage: 0
    glossary: 0
    media_library: 0
    redirect: 0
    redirect_404: 0
    scheduler_scheduled_content: 0
    taxonomy_term: 0
    user_admin_people: 0
    user_profile_display: 0
    watchdog: 0
    webks_inhalt_unterseiten: 0
    who_s_new: 0
    who_s_online: 0
  enabled_settings:
    argument: argument
    offset: 0
    limit: 0
    pager: 0
    title: title

I will create a follow-up issue for this.

Done, see here: #3445081: Add missing update hook for adjusting viewsreference field settings.