Download & Extend

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'bean.vid' in 'field list'

Project:Bean
Version:7.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

When upgrading from revision 49f116ead7a3b8eed6227dc6ecbcafcacdfe3a84 (Jul 18) to latest revision c210fc8bc900df3a7630504d87d8e2bbc227e670, I get the following error from update 7007:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'bean.vid' in 'field list'

Comments

#1

Status:active» closed (works as designed)

Ok, this is an issue because one of our own update hooks was running first, which was doing some cache flushes. Implementing hook_update_dependencies to ensure that the bean update ran first resolved the issue.

#2

Status:closed (works as designed)» active

I think this issue should not be let as is.
I ran into it today and spent hours trying to understand what was happening !

My case was not so complicated, after having integrated in my dev environment some modules then after having updated other ones, I tried to deploy these changes on my staging server but drush updb refused to work well.

I found this issue but I did not found where to put this hook. So I had to make it in my profile's install file to manage other modules update dependencies... Any common site builder would have been totally outworn by this issue.

Could we find a real "fix" for this ?

PS : I was also very stunned by the usage of bean_schema() in you update functions. What if the schema evolves a lot in future updates and an user try to update Bean from 7000 to an hypothetical 7030 version ?

#3

THe process we used to "fix" this was to follow these steps:

  • Update to the latest version of BEANS
  • edit the beans.install file and comment our ALL the updates after 7007, but leave 7007 so it will run.
  • run drush updb (or update.php)
  • edit the beans.install file and uncomment ALL the subsequent updates.
  • run drush updb (or update.php)
  • profit

if an implementation of hook_update_dependencies could be used to resolve this automatically, then it should be added to BEANs.

PS : I was also very stunned by the usage of bean_schema() in you update functions. What if the schema evolves a lot in future updates and an user try to update Bean from 7000 to an hypothetical 7030 version ?

I'm also surprised by this.