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

Files: 

Comments

a debug_backtrace() in ctools_export_load_object() would help a lot here:)

StatusFileSize
new27.96 KB

thanks rootatwc - backtrace attached

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

Project:File entity (fieldable files)» Media
Status:Active» Fixed

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

Status:Fixed» Needs review

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.

Status:Needs review» Needs work

Correcting status

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

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.

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.

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.';

new release blocker

Project:Media» File entity (fieldable files)

- updating file_entity
- running the below sql on the affected db

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_7201

are there any other errors in logs?

Status:Needs work» Postponed (maintainer needs more info)

for all other use cases above this commit should fix the problen
http://drupalcode.org/project/media.git/commit/9ef1709

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)

@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')

StatusFileSize
new51.26 KB

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]
update dependencies graph

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)

Issue tags:+7.x-2.0 alpha blocker

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?

#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.

Status:Postponed (maintainer needs more info)» Closed (cannot reproduce)
Issue tags:-7.x-2.0 alpha blocker

@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.