I've just updated the module from alpha 3 to alpha 4 and started seeing these:

Notice: Undefined property: stdClass::$field_view_title in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables() (line 1156 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_view_title' in 'field list':

I think it's due to the new field option for including the view title. It looks like the field is only added when the module is installed, so will existing users of the module need to re-install? Or can we create a hook_update() to add this field and support existing users? I'm happy to write a patch.

Comments

joekers created an issue. See original summary.

NewZeal’s picture

OK, that error is occurring because of already installed viewsreference fields. I have added an update script which should alter all preinstalled fields to alpha5. My apologies, I added a script for the argument field when I added it but not for the title field.

ravenstar’s picture

I've run into a similar problem updating from alpha4 to alpha5, but this time with the "_title" column. The update script runs through a set list of field types, but in my site one of the fields was associated with entities from the paragraphs module which aren't in that list. I'm not familiar with the code in enough detail, but I don't think it's possible to know in advance all the possible entities that might incorporate a viewsreference field, is it? Perhaps the updates should run through and update all applicable fields? I've found the following alteration to the update code to work:

  $fieldManager = \Drupal::service('entity_field.manager');
  $entityManager = \Drupal::service('entity.manager');
  $entityTypeManager = \Drupal::service('entity_type.manager');

  $types = array_keys($entityManager->getAllBundleInfo());

  foreach ($types as $type) {
    $entity_type = $entityTypeManager->getDefinition($type);

   /* Omit entities that aren't fieldable. */
    if (!$entity_type->isSubclassOf(\Drupal\Core\Entity\FieldableEntityInterface::class)) {
       continue;
    }

/* Remainder of update method, iterating over type's bundles, is unchanged */
NewZeal’s picture

The quickest way to eliminate the problem is to delete the field and recreate. Once we move out of alpha releases then we will hopefully not do anything that will break anyone's current site. Thanks for the code update.

joekers’s picture

Still no luck after using your code @ravenstar but thanks anyway!

Looks like I'm going to have to recreate all my viewsreference fields :(

NewZeal’s picture

Ah, sorry about that. We need to consider all possible modifications required at this level before we close off alpha and move to beta.

NewZeal’s picture

Status: Active » Closed (won't fix)
eugenechechel’s picture

Status: Closed (won't fix) » Needs work

This update needs to be reworked to update paragraphs, blocks and other fieldable entities. I have Column not found: 1054 Unknown column 'field_view_title' in 'field list': INSERT INTO {paragraph_revision__field_view}

When I've changed viewsreference_update_8101 to

$types = array(
    'node',
    'taxonomy_term',
    'user',
    'paragraph',
  );
  $fieldManager = \Drupal::service('entity_field.manager');
  $entityManager = \Drupal::service('entity.manager');
  foreach ($types as $type) {
    $bundles = $entityManager->getBundleInfo($type);
    foreach ($bundles as $bundle => $label) {
      $fields = $fieldManager->getFieldDefinitions($type, $bundle);
      foreach ($fields as $field) {
        if ($field->getType() == 'viewsreference') {
          $field_name = $field->getName();
          $definition = $field->getFieldStorageDefinition();
          $schema = $definition->getSchema();
          $id = $definition->id();
          $table = str_replace('.', '__', $id);
          if (!db_field_exists($table, $field_name . '_title')) {
            db_add_field($table, $field_name . '_title', $schema['columns']['title']);
          }

            $table = $type . '_revision__' . $field_name;
            if (!db_field_exists($table, $field_name . '_title')) {
              db_add_field($table, $field_name . '_title', $schema['columns']['title']);
            }

          }

      }
    }
  }

it works but Probably $types array should be dynamic.

jwjoshuawalker’s picture

Version: 8.x-1.0-alpha4 » 8.x-1.x-dev
Status: Needs work » Needs review
StatusFileSize
new1.7 KB

Here is a patch that fixes it for the existing hook_update_N entries, though we may want to add an 8102 to solve this. Let me know.

joekers’s picture

Thanks for the patch, but what happens if the views reference field is added to a user or taxonomy term entity?

We could do with this hook_update on #2848762: Add Number/Offset Field - this now applies to 2.x branch and when other fields are added in the future.

jwjoshuawalker’s picture

@joekers

user & taxonomy terms were already handled in the existing code.

joekers’s picture

Ah I see, I got confused when I saw this line :)
if ($type == 'node' || $type == 'paragraph') {

I'll give this a test with the issue I mentioned before then report back.

joekers’s picture

Status: Needs review » Closed (won't fix)

I tested with adding a new field from #2848762: Add Number/Offset Field - this now applies to 2.x branch and the patch works well.

However I feel that the whole update function needs re-writing - we should try to refactor the code into a new function which gets called each time from a hook_update, rather than duplicating most of the code each time. Also, as EugeneChechel said, we need to deal with blocks and other fieldable entities so I have opened a new issue to try to tackle this #2862022: Improve hook_updates when adding a new field.

Reverting status back to previous.