I've just tried to update from beta9 to beta10, but it fails in update 8032 because the table 'webform_submission_log' already existed at that moment. I've had a closer look at the code and first couldn't understand why.
I repeated the update process a few times, debugged it by removing 8032 and the upcoming ones and saw, that before 8032 the table actually already existed.
Then I rolled back again, removed all new updates and re-added them piece by piece. I finally saw that 8026 is the one to blame because it is running this code:
\Drupal::entityDefinitionUpdateManager()->applyUpdates();
I've unfortunately seen this in update hooks of a couple of other modules. This is actually very bad. Why? It runs all pending entity definition updates, even the ones of other modules. First, one module should never update on behalf of another one. Second, this can have unwanted and unpredictable side-effects on other modules (think of that module may will also have some update hooks, doing some important things before or during the definition updates. You'll preventing this unfortunately). And last but not least, obviously you can have unpredictable side effects even within your own update hooks.
In the end, this shows a great weakness of Drupal core in this area. These things are not documented well, and much worse imho the API in this area is not developer friendly. There's unfortunately no "applyUpdate()" function, which can be parameterized to run a speicific single entity definition update. There's only the all or nothing function that was used here. If you have a closer look on the applyUpdates() function, you'll see that a lot of protected functions are called inside, I've once written an update helper in a custom project to accomplish that and I had to duplicate a lot of code there from these functions. So I'll think, we should contact Core contributors, if there are already plans to extend this API here. I'm currently preparing a small blog post to point that problem out to other module maintainers.
edit: here's my blog post about this topic: https://www.agoradesign.at/blog/why-running-drupalentitydefinitionupdate...
| Comment | File | Size | Author |
|---|---|---|---|
| #62 | Fixing mismatched entity and:or field definitions.png | 120.89 KB | lomale@bluewin.ch |
| #48 | updating_from_beta9_to-2866957-48.patch | 4.69 KB | jrockowitz |
| #47 | updating_from_beta9_to-2866957-46.patch | 6.86 KB | jrockowitz |
| #42 | webform-table.png | 695.57 KB | jrockowitz |
| #42 | yamlform-table.png | 720.49 KB | jrockowitz |
Comments
Comment #2
agoradesign commentedThe best documentation on how to apply entity definition updates in update hooks I've found is this change record: https://www.drupal.org/node/2554097
Comment #3
agoradesign commentedComment #5
jrockowitz commented@agoradesign Thank you for pinpointing the exact issue with beta10 update.
I could not reproduce this issue via 8.2 or 8.3 using the below steps...
git checkout 8.x-5.0-beta9drush site-installgit checkout 8.x-5.xorgit checkout 8.x-5.0-beta10drush updborupdate.phpNevertheless, I completely believe that there is a serious issue with
webform_update_8026()executing all pending entity updates. The bottom line is users must rundrush entity-updatesafter all the updates have been applied.The attached patches just disables the entity update call in
webform_update_8026()and displays warnings which links to https://www.fuelforbrain.com/drupal-8-mismatched-entity-andor-field-defi...Some notes...
Comment #6
agoradesign commentedHmm, your experiences are interesting... I did not expect the that the table gets created either, but it did.. And I tried the update process several times. It was on a local development site I'm currently working on, running 8.3.0-rc2. There are two webforms currently, but without any submissions at all. 8026 was always adding the table for me
I hope, your users will read the message of the update hook carefully. Otherwise you'll get a lot of bug entries here... A more dirty approach (because of leaving the unwanted call) that would at least cause no Webform-internal problems would be to leave 8026 as it is for the meantime and wrap some check if the table exists in 8032.
Comment #7
agoradesign commentedI've another site in rather the same development state as the one with the update problem. Webform should be in beta9 too... I'll try an update there and report back, if the problem happens there as well
Comment #8
agoradesign commentedSame problem on the other site:
Then I restored my DB backup and removed update 8026 - 8032 from the file, ran updatedb again. Table was still missing. Then re-added 8026 and executed updatedb --> table was there.
Comment #11
jrockowitz commented@agoradesign Thank you for fully documenting this issue in blog post.
I agree telling users to execute `drush entity-updates` is going to create more problems than it solves.
Let's add the tableExists() call to webform_update_8032() and move the \Drupal::entityDefinitionUpdateManager()->applyUpdates(); call to end of the hook_update_N().
I am hoping the worst case scenario is that the webform module will need to updated independent of other core and contrib updates.
Comment #12
agoradesign commentedyou're welcome :)
btw, maybe your different experience in #5 was due to differently cached information. catch was pointing me to a Core issue that has already been fixed, where an update in comment module was not updating correctly the field storage definition of the status field. Especially this comment explains the situation very well: #2841614-12: comment_update_8300 is not updating correctly the field storage definition of the status field
Comment #14
jrockowitz commentedI think I really have to fix the update hook.
Comment #16
jrockowitz commentedThe attached patch is hopefully now updating the field storage and table schema the 'right' way.
To help make it easier to future update hooks I create the below helper functions.
_webform_update_field_storage_definitions();
_webform_update_webform_submission_storage_schema();
At some point, I might add these helpers to the `drush webform-repair` command.
I just need some confirmation that the updates are working correctly and I will tag a new release.
Comment #18
jrockowitz commentedWow, this is really frustrating, locally the webform_log_submision table has to always be manually created via the update hook.
I think this final patch makes sure the webform_log_submision table is created and all pending webform entity updates are up-to-date.
Comment #19
agoradesign commentedI'll try it
Comment #20
agoradesign commentedGood news: it worked on the exact same site (really the exact same database state), where it failed yesterday :))
After paying some attention to this topic yesterday and having a very good conversation with catch on IRC, I'll add some thoughts with you, which hopefully are not frustrating you more... ;)
The two very positive things of this patch are:
There's a last chance of future complications nevertheless with the new approach. 8026 and 8032 now both update according to the schema structure at time of running the update, not at the time of you're writing your update scripts. It's like the situation in D7 or earlier, where it worked in 99% of the cases to load the current schema from hook_schema and run updates. But that could cause troubles and therefore was discouraged, instead hardcoding the schema in the update hook was the way to go. see the linked issue in my comment #12 e.g.
So what I wanted to say that the best version of 8032 was in #11 imho, whereas 8026 is much better now, but not perfect. However, I would not do any further changes now. It works atm perfectly. And webform is still in beta, so it's absolutely arguable. After final release, the schema will not change that frequently anyway, and if it does, it's up to you to solve it differently
Comment #22
jrockowitz commentedI agree that this just needs to be fixed ASAP, so I am committed the fix and will tag a new 'hotfix' release.
BTW, Webform 8.x-5.x is definitely staying in beta while the schema and API are worked out. Ideally, RC and final releases won't require immediate hotfixes to address unforeseeable issues in the update process.
Comment #23
agoradesign commentedfully agree :) thanks for this quick hotfix!
Comment #24
geerlingguy commentedThanks for the quick fix; I had updated things yesterday and all the sudden my CI workflow ground to a halt. It wasn't entirely obvious what was causing the issue, but commenting out the code in 8032 seemed to fix it... it looks like this patch/beta11 also works great, so I just updated again this morning, and it's working!
For the benefit of SEO for English users, I'll paste the error I was getting during updates:
Comment #25
rdw99 commentedHello Jacob
I was able to successfully update to first beta 10 then beta 11. However I'm seeing an error reported in the Status Report that the Web Form Submission entity type needs updated. Please see attached screenshot (Webform_mismatched_entity).
Could you please provide some instructions on how to troubleshoot and resolve this issue?
Thank you.
Robert
Comment #26
rdw99 commentedComment #27
rdw99 commentedComment #28
agoradesign commentedI fear, jrockowitz will crazy now... I have absolutely no clue, how this is even possible to happen... we all had problems with beta10 that the table was being tried to be created twice, and on your site there isn't even one attempt? that's really weird...
There were for sure no problems during DB update?
Do have backups from before the update, being able to reproduce and debug?
Comment #29
jrockowitz commented@rdw99 You should try
drush eval "module_load_install('webform'); webform_update_8032();".Ideally, you should revert the db to pre beta10, update to beta11, and the updates should work fine.
Comment #30
jrockowitz commented@agoradesign I am getting close to adding "THIS IS A BETA RELEASE!!! BACKUP AND TEST YOUR WEBSITE AFTER YOU APPLY THIS UPDATE." disclaimer to all my release notes.
Comment #31
agoradesign commentedhaha, maybe you should :D but I think, that #25 was a special case due to any reason, but I see no reason, why your update script should fail
Comment #32
rdw99 commentedHello Jacob
The issue that I reported in #25 was something that occurred in our sandbox environment. I installed beta 11 on our DEV/QA environments and everything works like a charm. Now I have a Contact Us form on our Website that satisfies the needs of our users.
Thanks for your response. Take care.
Regards,
Robert
Comment #33
jrockowitz commentedMarking as fixed.
Comment #34
rdw99 commentedHello Jacob
Sounds good. I appreciate your reply.
FYI...
I just wanted to give you some additional information for the issue that I reported in #25. This probably occurred because I installed the two dev releases after beta 9 and before installing beta 11. I now have my sandbox environment running on beta 11 with no issues in the status report. I restored the environment from backup where beta 9 was installed. I then installed beta 11 again with no issues.
Thank you.
Robert
Comment #35
lomale@bluewin.ch commentedI tried to update as recommended
but got this error message, over and over again while trying to run the database update.
webform-Modul
Update #8026
• Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'webform_open' in 'where clause': SELECT 1 AS expression FROM {node_revision__webform} t WHERE ( (webform_target_id IS NOT NULL ) OR (webform_default_data IS NOT NULL ) OR (webform_status IS NOT NULL ) OR (webform_open IS NOT NULL ) OR (webform_close IS NOT NULL ) ) LIMIT 1 OFFSET 0; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (Zeile 1478 in /var/www/web195/html/drupal8/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)
with all your comments above, I don't know now what I can do about it and what will happen with my forms that are running.
Can somebody help.
Thank you
Comment #36
jrockowitz commented@lomale@bluewin.ch Try running
Make sure the check your status report.
Comment #37
jrockowitz commentedMoving to active since people are still having issues.
Comment #38
ehanuise commentedSame problem, upgrading from 8.x-5.0-beta4 to 8.x-5.0-beta11
Update #8026
• Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'webform_open' in 'where clause': SELECT 1 AS expression FROM {node_revision__webform} t WHERE ( (webform_target_id IS NOT NULL ) OR (webform_default_data IS NOT NULL ) OR (webform_status IS NOT NULL ) OR (webform_open IS NOT NULL ) OR (webform_close IS NOT NULL ) ) LIMIT 1 OFFSET 0; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException()
I tried to understand what the code does, but i'm not a coder... From what I understood, extra columns webform_open and webform_close should be added to the webform node and node revision tables, and it didn't happen. Not sure this is #8026 misbehaving, aren't these tables added by #8025 ? (again i'm not a coder, i'm a sysadmin. And by the way, is there any place I can see the database schema of modules ? I would like to be able to check the DB schema against the correct schema to understand what is missing when a db update fails...)
I reverted to 8.x-5.0-beta4 in the meanwhile.
Comment #39
jrockowitz commented@ehanuise I think the problem is my update hooks are not working across multiple beta releases. This is VERY hard and time consuming for me to debug. The good news is as more developers like @agoradesign get involved, they are able to catch my mistakes before they become too difficult to fix.
You could try doing incremental updates using Drush...I hope no one shoots me for suggesting this solution.
Comment #40
ehanuise commentedWill try, but it'll have to wait next week - was doing a quick update of the site with limited time, and i've been four hours at it already :/
restoring beta4 was a quick and dirty fix but it buys me the time I need now, until a definitive fix comes.
(and again, knowing the target table structure would help a lot.)
Anyways, thanks a lot for your efforts - it's always nag and complain here, but of course your work is much appreciated ;-)
Comment #41
wheelercreek commentedI think I have found the issue - I don't know if it's exactly the same thing you are seeing.. but I decided to finally run the script to switch over from YAML_form to Webform and then when I tried to run the updates with Drush it also got stuck on Update 8026. For me it turned out that the problem was really 8025, and the open / closed database columns never got created successfully.
in webform.install line 770, there's a test on the string: "Flag to control whether this webform should..." but the field description is actually:
"Flag to control whether this form should..." so that test failed & the columns never were created.
I ended up creating a new custom module & dropping in the update 8025 with that word change and it works now.
Hope that helps!
Comment #42
jrockowitz commented@wheelercreek I think you found the issue. I did a yamlform to webform migration and the webform.status db column has no description.
See the attached screenshots.
Comment #43
shawn dearmond commentedI ran into a similar issue too. Basically, the status and draft values for every form was wrong, and each webform's settings page would error.
This is what I ran:
Comment #47
jrockowitz commentedBecause I just recently started archiving old update hooks, the attached patch will only work for 8.x-5.x-dev.
When update the webform fields I am now looking for the specific webform field name and table name. This should allow people who migrated from the YAML form module to apply webform_update_8025().
Comment #48
jrockowitz commentedCleaning up the patch.
Comment #49
fahadurrehman commentedI have tried this patch updating_from_beta9_to-2866957-48.patch on latest dev version but again updates failed.
webform module
Update #8026
Failed: Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'webform_open' in 'where clause': SELECT 1 AS expression FROM {node_revision__webform} t WHERE (webform_target_id IS NOT NULL) OR (webform_default_data IS NOT NULL) OR (webform_status IS NOT NULL) OR (webform_open IS NOT NULL) OR (webform_close IS NOT NULL) LIMIT 1 OFFSET 0; Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1478 of /home/houstona/public_html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Comment #51
jrockowitz commentedI am stumped. When I do a clean install of beta9 and then switch to the latest dev release with the patch, the update hooks execute perfectly.
Can you try manually execute the below code? Does this fix the issue?
A question...
A thought...
Comment #52
fahadurrehman commentedThanks for the reply.
Yes I have migrated from YAML Form
after running
I have again updated the drupal and now getting new error
The update process was aborted prematurely while running update #8038 in webform.module. All errors have been logged. You may need to check the watchdog database table manually.
Also may be following log message can be useful for you
Notice: Undefined index: library in webform_update_8038() (line 405 of /home/houstona/public_html/modules/webform/webform.install) #0 /home/houstona/public_html/core/includes/bootstrap.inc(552): _drupal_error_handler_real(8, 'Undefined index...', '/home/houstona/...', 405, Array) #1 /home/houstona/public_html/modules/webform/webform.install(405): _drupal_error_handler(8, 'Undefined index...', '/home/houstona/...', 405, Array) #2 /home/houstona/public_html/core/includes/update.inc(178): webform_update_8038(Array) #3 [internal function]: update_do_one('webform', 8038, Array, Array) #4 /home/houstona/public_html/core/includes/batch.inc(252): call_user_func_array('update_do_one', Array) #5 /home/houstona/public_html/core/includes/batch.inc(95): _batch_process() #6 /home/houstona/public_html/core/includes/batch.inc(77): _batch_do() #7 /home/houstona/public_html/core/modules/system/src/Controller/DbUpdateController.php(186): _batch_page(Object(Symfony\Component\HttpFoundation\Request)) #8 [internal function]: Drupal\system\Controller\DbUpdateController->handle('start', Object(Symfony\Component\HttpFoundation\Request)) #9 /home/houstona/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(110): call_user_func_array(Array, Array) #10 /home/houstona/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(73): Drupal\Core\Update\UpdateKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request)) #11 /home/houstona/public_html/update.php(28): Drupal\Core\Update\UpdateKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #12 {main}.
Comment #53
jrockowitz commentedI literally just caused the webform_update_8038() issue. I am not sure why webform_update_8025(); was not originally executed.
Is your 'Status report' (/admin/reports/status) also okay?
Comment #54
fahadurrehman commentedStatus reports showing following errors
Out of date
Some modules have database schema updates to install. You should run the database update script immediately.
ENTITY/FIELD DEFINITIONS
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Webform submission
The Webform field needs to be updated.
And Following Warning
MODULE AND THEME UPDATE STATUS
Out of date
There are updates available for one or more of your modules or themes. To ensure the proper functioning of your site, you should update as soon as possible. See the available updates page for more information and to install your missing updates.
Some more warnings like webform ckeditor lirary etc... but I think that is not relevant to this issue atleast
Comment #55
jrockowitz commented@digitalexperts
Technically you should be able to run the below commands which should fix your 'Status report'.
What update hooks are pending?
Even, if this works. I think you should revert to your backup without the latest release, check the 'Status report' and see what is happening before any update hooks are executed. It is possible that you need to run
drush entity-updatesbefore updating the Webform module.Comment #56
r81d3r commentedI'm having the same issues trying to update my webform-beta9 to the current version:
1. I updated from an older version to beta9 / no problems so far
2. I installed the latest dev release and applied patch 48
3. When running db updates i get the following failures on 8025 and 8026:
4. drush entity-updates fails also:
5. drush eval "module_load_install('webform'); webform_update_8025();" fails:
6. drush eval "module_load_install('webform'); webform_update_8026();" fails also:
I didn't migrate from YAML form module
Comment #57
agoradesign commentedOne thing that everyone having problem seem to have in common, is that they all use webform_node sub module because I see "node__webform" and/or "node_revision__webform" in every stack trace posted here
Comment #58
jrockowitz commentedwebform_update_8025() is the issue because the 'webform_status' is not being changed from an int to varchar(20) column and the 'webform_open' and 'webform_close' columns are not being created.
I think
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'geschke-hosting.node__webform'is the key problem because I am trying to figure out the webform field table name, it is not working, and then throwing this errorSomeone needs to debug what is being returned by
$webform_tables = WebformEntityReferenceItem::getTableNames();in webform_update_8025() and see if the table names are correct.Comment #59
jrockowitz commentedIf someone is having this problem and going to be in Baltimore, maybe we can meet up and fix this at DrupalCon.
Comment #60
ehanuise commented@jrockowitz
Hi.
I tried the 'drush dl previous modules incremntally' approach you suggested. It failed too.
I think I strated the site with yamlforms and then moved to webform a while ago.
Here's the logs I get. I reverted to beta4 again, waiting for a fix.
I also tried a drush entity-update :
Comment #61
fahadurrehman commentedAfter the latest update the issues was solved for me.
Comment #62
lomale@bluewin.ch commentedI just want to contributed how I managed to fix the problem showed in the status report
i was able to run the script in Devel PHP shown in the picture.
But I'm not sure if this helps to fix the problem.
Fixing mismatched entity and/or field definitions.png
hope this helps for people that still don't make it installing composer and drush
Comment #63
jrwest_webguy commentedFixed Webform -- YAML form to Webform conversion
I've been hacking away at this issue for a few days now. Finally fixed Webform (with 8.x-5.0-beta12), and some additional cleanup of my environment. Complicating this issue was that I was trying to move my YAML form from a COMPOSER-managed YAML form module, to a Drush-installed version of the Webform module. Fortunately, I had only built 1 YAML form, and it had no results table. I say fortunately, because ultimately, the YAML form was lost in the conversion. It may have fared better if it was a drush-installed version of YAML form to drush-installed Webform; but, I will never know.
Enough background . . . onto the solution! Initially, I was getting the error for database update (8025 and 8026), when I updated from beta9 (I think) to beta11. My inclination was to uninstall Webform and downgrade back to beta9.
When I went to use drush pm-uninstall webform, the FIRST error I encountered was that the field 'node.webform' was still in use. I uninstalled each of the webform 'sub-modules' 1-by-1, including webform_templates, webform_examples, webform_ui, etc. I deliberately left webform_node as the last sub-module to 'drush pm-uninstall', expecting it to throw an error. I was pleasantly surprised when it uninstalled cleanly on the first try. However, my pleasure was short-lived, because, when I went to uninstall webform itself (the main module), using the command drush pm-uninstall webform, I still got the 'node.webform' error.
Having hit that brick wall, I decided I would just try and install the beta9 version of webform, right over top of the beta11 version. However, when I tried to run drush en [meaning download AND install] webform-8.x-5.0-beta9, drush would get stuck in an 'install loop'; stating that the module was not found, but this 'other' module with the same exact name seemed to fit the bill. Drush would then download the module, but when it tried to enable the module, it would throw the 'not found' error again, and then re-prompt me to download the 'other' module.
Despite the error loop for the beta9 install, it seems to have completed, because i tried a drush updb command, and it had no errors -- because it was not doing database updates for beta11. Yay! I have webform working again!
But wait, there's more . . .
Now I went about re-enabling (downloading and installing) the sub-modules, which are really the important part of Webform. I decided to start by enabling the webform_node sub-module first, using the command drush en webform_node. This command threw the SECOND error I encountered, saying 'Webform content already exists, please delete the Webform content type before installing the Webform node module.' So, on my site, I went to Structure > Content types > and clicked the 'Delete' option on the 'Operations' menu associated with the Webform content type.
After having deleted the 'content type' from the site, I decided that rather than try and re-enable the sub-modules for webform-beta9, I would attempt a 'clean', drush-based, install of webform-8.x-5.0-beta12. So, my next step was to again attempt an uninstall of the main, webform (beta9) module; using the command drush pm-uninstall webform. This time, I did not get the 'node.webform' error; instead, I got a 'Fields pending deletion' error.
To resolve this THIRD error, you need to do the following three steps, move the webform module's folder, run cron update (drush cr all) several times, and then put the webform module's folder back in it's original location, /modules/contrib/webform.
Did those three steps, then, using the website's 'Extend' tab -- where all the modules available to be enabled are represented -- I checked the boxes for all of the webform modules and sub-modules that I wanted enabled. This lead me to my FOURTH error -- 'webform (or whatever module) already exist in active configuration'. To fix this error, I did the following:
Now everything seems to be working fine! :)
Comment #64
jrockowitz commentedThis is definitely a related issue.
Comment #65
tijsdeboeckpatch #47 workt for me, it also hung at 8026.
drush updb & drush entity-updates worked perfectly after the patch.
Comment #67
jrockowitz commentedI committed patch #47 because it addresses webform_update_8025() failing because a site is using table prefixes.
I still think there is an issue with webform_update_8025() that cause webform_update_8026() to fail but I can't reproduce this issue.
Anyone having issues with webform_update_8025() needs to start debugging the problem and help me this figure out.
Comment #68
emdahlstrom commentedThe latest dev solved this issue for me
Comment #69
jrockowitz commentedIs anyone still having problems?
I think the next step would be for me to write a debugging patch or drush command that outputs the table scheme right before webform_update_8025() is executed.
Comment #70
ehanuise commentedHi @jrockowitz
I tried the latest dev (from 05 may) still no luck. :/
Is there any way to export all existing forms (not the contents - I can export these as a file and keep this for reference, but the form definition, including email handlers and other configs), and to reimport them? I'm considering deleting all webforms and nodes with webforms, uninstalling the module and deleting all DB fields, and installing a clean wemforms modules and reimporting all existing forms and nodes.
Comment #71
ehanuise commented@jrockowitz I think this time I got it to work...
==> I edited my 'webform' node type and removed the webform field.
Once that was done I was able to perform the entity update, and then apply the various db updates.
Once that has been done, I've been able to add the webform field to my node type, and re-link the webforms to the nodes.
No node or webform subs/configs lost in the process - all good :-)
Comment #72
jrockowitz commented@ehanuise Your work around makes sense. The issue is definitely the field updates occurring in webform_update_8025().
Hopefully someone with issues updating will be able to debug this hook. I would like to figure out what is breaking so that I can't this problem in the future.
Comment #73
ehanuise commentedSorry I can't help further.
A fix strategy could be to check for the presence of the new table columns, and matching fields, and to create them if missing.
But yes, this could lead to corruption.
Comment #74
davy-r commentedI didn't read the complete thread, so excuse me if this info is already known.
I updated webform from 5.0.0-beta9 to dev-5.x 915d3e7, but 8025+8026 still fail with the following errors:
Comment #75
gngn commentedI experienced the same error "Unknown column 'webform_open' in 'where clause'" described above (running
drush updatedb).I migrated my D6 webforms to D8 via yamlform, yaml_migrate, ... so I wanted to keep the migrated webforms.
Here is what worked for me:
The whole content type was created by the migration (I think). I did not need it, so
drush updatedbhad no problems!I re-imported the config for field "Webform" in content type "Webform", so I even got that back.
Comment #76
r81d3r commentedFinally the solution provided in #75 did the trick for me, too.
Very easy and fast workaround.
Comment #77
fahadurrehman commentedTried every thing in this thread but getting the following errors.
drush updb -y;
The following updates are pending:
webform module :
8026 - Issue #2857417: Add support for open and close datetime to Webform nodes. Update entity definitions.
8027 - Issue #2857417: Add support for open and close datetime to Webform nodes. Update field config settings.
8028 - Issue #2859528: Add reply-to and return-path to email handler.
8029 - Issue #2856842: Allow emails to be sent to selected roles.
8030 - Issue #2838423: Drafts for anonymous users.
8031 - Issue #2854021: Send email based on element options selection.
8032 - Issue #2854020: Provide a mechanism to log submission transactions.
8033 - Issue #2864851: Allow form builder to opt-in to converting anonymous draftssubmissions to authenticated draftssubmissions.
8034 - Issue #2865353: Improve submission log integration.
8035 - Issue #2867529: Email handler states setting should be index array.
8036 - Issue #2867855: Add category support to webform config entity.
8037 - Issue #2868075: Token types are not defined but have tokens.
8038 - Issue #2870218: Improve External Library Management.
8039 - Issue #2871215: Copied webform templates should not have dependencies.
8040 - Issue #286655: Add Quick Edit off canvas form.
8041 - Issue #2871606: Add (optional) support for Chosen.
Do you wish to run all pending updates? (y/n): y
Exception thrown while performing a schema update. SQLSTATE[42S22]: [error]
Column not found: 1054 Unknown column 'webform_open' in 'where
clause': SELECT 1 AS expression
FROM
{node_revision__webform} t
WHERE (webform_target_id IS NOT NULL) OR (webform_default_data IS NOT
NULL) OR (webform_status IS NOT NULL) OR (webform_open IS NOT NULL)
OR (webform_close IS NOT NULL)
LIMIT 1 OFFSET 0; Array
(
)
Performing webform_update_8026 [ok]
Failed: Exception thrown while performing a schema update. [error]
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'webform_open'
in 'where clause': SELECT 1 AS expression
FROM
{node_revision__webform} t
WHERE (webform_target_id IS NOT NULL) OR (webform_default_data IS NOT
NULL) OR (webform_status IS NOT NULL) OR (webform_open IS NOT NULL)
OR (webform_close IS NOT NULL)
LIMIT 1 OFFSET 0; Array
(
)
Comment #78
fahadurrehman commentedFInally Issue resolved by deleting the webform field from all content types which were using that.
Thanks to #75
Comment #79
cyberschorschI am also currently looking into this with an existing project which runs on a old dev version.
The issue here is the update 8025 which adds the new columns to webform field storage tables. We are using a paragraph bundle which has a webform field and has enabled revisions. When running the update hook, only the field table will be updated, but not revision archive storage tables.
If we take a look into the error reports in this issue, we can see that many users are using webform_node with enabled revisions and suffer the same problems. I think we have to fix the update hook supporting revision schema updates.
Comment #80
jrockowitz commented@everyone Please see #2888811: webform_update_8025 fails with table prefixes.
Comment #81
jrockowitz commented#2888811: webform_update_8025 fails with table prefixes should have resolved this issue. Please reopen if anyone is still having problems updating.
Comment #82
jrockowitz commented