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.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | viewsreference--update-hook-problems-2824292-9.patch | 1.7 KB | jwjoshuawalker |
Comments
Comment #2
NewZeal commentedOK, 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.
Comment #3
ravenstar commentedI'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:
Comment #4
NewZeal commentedThe 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.
Comment #5
joekersStill no luck after using your code @ravenstar but thanks anyway!
Looks like I'm going to have to recreate all my viewsreference fields :(
Comment #6
NewZeal commentedAh, sorry about that. We need to consider all possible modifications required at this level before we close off alpha and move to beta.
Comment #7
NewZeal commentedComment #8
eugenechechel commentedThis 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
it works but Probably $types array should be dynamic.
Comment #9
jwjoshuawalker commentedHere is a patch that fixes it for the existing
hook_update_Nentries, though we may want to add an 8102 to solve this. Let me know.Comment #10
joekersThanks 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.
Comment #11
jwjoshuawalker commented@joekers
user & taxonomy terms were already handled in the existing code.
Comment #12
joekersAh 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.
Comment #13
joekersI 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.