Posted by russellb on November 5, 2012 at 2:14pm
13 followers
| Project: | File entity (fieldable files) |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (cannot reproduce) |
| Issue tags: | 7.x-2.0 alpha blocker |
Issue Summary
updatedb is giving us error table file_type doesn't exist on updatedb from 7.x-2.0-unstable6 to latest dev:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'os_dev.file_type' doesn't exist [error]
An error occurred at function : drush_core_updatedb_batch_process [error]
WD menu: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table [error]
'os_dev.file_type' doesn't exist: SELECT t__0.*
FROM
{file_type} t__0; Array
(
)
in ctools_export_load_object() (line 427 of
.../modules/contrib/ctools/includes/export.inc).
Any clues gratefully investigated.
Thanks,
Russell
Comments
#1
a debug_backtrace() in ctools_export_load_object() would help a lot here:)
#2
thanks rootatwc - backtrace attached
#3
We have had some progress on this issue today by updating file_entity first and separately from media. We suspect this problem occurs if you update file_entity and media on the same update db
#4
I think you are right. Media's 7209 has not register the file_entity 7201 as depepndency
i made a commit
http://drupalcode.org/project/media.git/commit/93bf919
Lets hope this fixes it
#5
We still have the same problem there I'm afraid with latest dev.
So when we upgrade from unstable6 of media and file_entity to latest dev. of both we still get the errors above.
Our work-around still works with latest dev - put the new files on for file_entity and run updatedb, then new files on for media and updatedb
We are moving forward now with our 2 stage work-around here.
#6
Yep - see #1844174: Update #7208 Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation
I found this issue after I posted that one.
#7
Correcting status
#8
I am confused. I have 7.x-2.0-unstable7 versions of both file_entity and media with the error
Update #7208 Failed
What is the work around?
Should I be using dev versions or working around with these versions?
Is this problem important on a live site?
Thanks, Jerry
#9
Our work-around was as follows:
- get the new files for file_entity
- put them in place in your modules directory
- run drupal update db
- get the new files for media
- put them in place in your modules directory
- run drupal update db
When we encountered this problem unstable7 wasn't quite out yet, so I don't know for sure if this works with unstable7, but I expect it does.
As to whether it is important on a live site, I would be nervous myself about database updates failing on a live site. We ran test deployments on our development servers before taking this to our live site.
#10
I'm getting the same error trying to update both file_entity and media from unstable6 to unstable7.
I had the same idea to update first file_entity then media, but that's not working for me.
#11
I was able to get this working by:
- updating file_entity
- running the below sql on the affected db
- updating media (and media_youtube) modules
-- --------------------------------------------------------
--
-- Table structure for table `file_type`
--
CREATE TABLE IF NOT EXISTS `file_type` (
`type` varchar(255) NOT NULL DEFAULT '' COMMENT 'The machine name of the file type.',
`label` varchar(255) NOT NULL DEFAULT '' COMMENT 'The human readable name of the file type.',
`description` mediumtext NOT NULL COMMENT 'A brief description of this file type.',
PRIMARY KEY (`type`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Stores the settings for file types.';
-- --------------------------------------------------------
--
-- Table structure for table `file_type_mimetypes`
--
CREATE TABLE IF NOT EXISTS `file_type_mimetypes` (
`type` varchar(255) NOT NULL DEFAULT '' COMMENT 'The machine name of the file type.',
`mimetype` varchar(255) NOT NULL DEFAULT '' COMMENT 'Mimetypes mapped to this file type.',
KEY `file_type` (`type`),
KEY `file_type_mimetype` (`mimetype`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Maps mimetypes to file types.';
-- --------------------------------------------------------
--
-- Table structure for table `file_type_streams`
--
CREATE TABLE IF NOT EXISTS `file_type_streams` (
`type` varchar(255) NOT NULL DEFAULT '' COMMENT 'The machine name of the file type.',
`stream` varchar(255) NOT NULL DEFAULT '' COMMENT 'Streams mapped to this file type.',
KEY `file_type` (`type`),
KEY `file_type_stream` (`stream`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Maps mimetypes to file types.';
#12
new release blocker
#13
so after running file entity updates tables are not there?
if so this is not a race condition/cache problem as i suspected..
this is freaking weird to be honest, something is wrong with
file_entity_update_7201are there any other errors in logs?
#14
for all other use cases above this commit should fix the problen
http://drupalcode.org/project/media.git/commit/9ef1709
#15
Maybe use hook_update_dependencies
for proper ordering of hook_update_N() and add dependencies in media.info and or file_entity.info like
dependencies[] = file_entity (>=7.x-2.0-unstable7)#16
@technivant: could you check schema versions of media and file_entity in system table BEFORE the upgrade?
Run:
SELECT name, schema_version FROM `system` WHERE name in ('media', 'file_entity')#17
I did the following
media $ git checkout 7.x-2.0-unstable6
file_entity $ git checkout 7.x-2.0-unstable6
drush site-install
drush en media --yes
media $ git checkout 7.x-2.0-unstable7
file_entity $ git checkout 7.x-2.0-unstable7
drush uli
and finish manually without trouble.
Next
media $ git checkout 7.x-2.0-unstable6
file_entity $ git checkout 7.x-2.0-unstable6
drush site-install
drush en media --yes
media $ git checkout 7.x-2.x
file_entity $ git checkout 7.x-2.x
drush uli
and finish manually without trouble.
So running update.php from within the browser is no problem. (Hope that helps a tiny bit)
[edit: image is dependencies graph latest dev]
#18
As we have changed media_update_dependencies a few times
- [#1832297]
- #1846518: Document file types are undefined after module update
it is possible schema versions are installed not in sync between media and file_entity.
Could it be update_resolve_dependencies skip dependency check and install out of order? At least that's how I read the code
<?php// If the update function is missing and has not yet been performed, mark
// it and everything that ultimately depends on it as disallowed.
if (update_is_missing($module, $number, $update_functions) && !update_already_performed($module, $number)) {
?>
(my 2 cents)
#19
#20
In #17 I had no trouble to upgrade.
So my guess now is this is not a release blocker.
@Dave Reid why is this a release blocker now?
#21
#18 sounded like there was more to investigate and this wasn't fully resolved. If that's incorrect, then feel free to remove the blocker tag.
#22
@Dave Reid you are right the phrasing could have been better.
I hope the others would agree with cannot reproduce.
Rereading #14 it is probably fixed due to the commit mentioned in #14.
So I remove the release blocker and set to cannot reproduce as try to show with #17.
Feel free to reopen.