Problem/Motivation

In certain circumstances, installation of the Media module can fail with the following error:
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mydatabase.media_type' doesn't exist
Splitting this off from #1290556: Error during install as that was really a separate issue.

One trigger for this issue is when a module calls API methods in a default hook implementation. An example is in advanced_forum_views_default_views().

Proposed resolution

The current patch in this issue, in #13, adds an explicit test for db_table_exists(). This change prevents the error, but there are outstanding questions as to whether this is the correct fix.

While this error appears in Media, its solution may properly lie elsewhere. It would seem unreasonable to expect that every hook implementation should test to ensure its module's tables are in place in case it's incorrectly invoked by another module before it's completed installation. Perhaps the onus to address/avoid premature data calls should be on modules invoking API calls from within default hook implementations.

#1311820: Don't do a registry_update() before installing a module is an issue on Drupal core that attempts to diagnose and address the causes of this bug.

Remaining tasks

User interface changes

API changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DamienMcKenna’s picture

The path of execution is:

  • module_enable()
  • -> registry_update()
  • -> ctools_registry_files_alter()
  • -> _ctools_registry_files_alter()
  • -> (not sure exactly, was taking too long to debug it)
  • -> media_file_type_info()
  • -> media_type_get_types()
  • -> BOOM!
DamienMcKenna’s picture

Status: Active » Needs review
FileSize
623 bytes

Here's a patch that changes media_tye_get_types() to return an empty array if an installation profile is running and the schema doesn't exist. I've tested this twice and it was able to continue on without any further problems, from Media.module at least ;-)

rickvug’s picture

@DamienMcKenna Thank you for the patch, it is a life saver! I was having this exact problem within an installation profile and the above patch fixed the problem. Using latest media and file entity code. I don't know enough about Media to comment on the approach so no RTBC. Otherwise the patch does look good.

DamienMcKenna’s picture

I'm wondering if it should be make more generic, because the scenario that causes the registry_update() to execute media_file_type_info() shouldn't be limited to just when running an installation profile, e.g.:

+  // Check for whether this is being executed during registry_update() from
+  // within an installation profile *before* the schema has been created.
+  if (!db_table_exists('media_types')) {
+    return array();
+  }
+
girishmuraly’s picture

Any help if I point out that the SQLSTATE[42S02] error does not occur on php 5.2.9 but does on 5.3.3?

DamienMcKenna’s picture

@girishmuraly: Thanks. I've been using PHP 5.2.13 locally, while my installation worked fine on v5.2.4-2ubuntu5.17 on a server a month ago; of course in that month a lot of the codebase has changed.. Am going to try with a newer 5.2 and see what happens.

DamienMcKenna’s picture

I just confirmed it also fails with PHP v5.3.2 on MAMP.

emptyvoid’s picture

Follow up,

This error on line 128 of the media.type.inc causes most configuration pages to never completely submit.

The entire configuration section of the admin won't render the configuration forms and in the event a configuration form appears submitting will result in the error.

Reviewing the media.install file I think it has been built wrong. Normally you define the correct schema for default creation during install, and it matches your current business logic in the code. The updates modify the schema to match what the default install should add into the database. This assumes that past releases need to be updated to match the "default" schema.

However, in the install file it is inverted, the default schema created is an old schema and updates modify the schema to what the code expects it to be. From my testing the updates never get called and the schema is never correctly defined.

Also I have found that if you do issue updates that each update should set the schema to exactly what it is expected to be for the current business logic. The updates I've reviewed tweak different parts of the schema instead of defining the whole schema.

If this did work in installations with php 5.2 I can only assume there is a conflict with the install/update classes and the way the schema and install hooks were coded resulting in the code not working on php 5.3.

Thoughts?

DamienMcKenna’s picture

I still think there's a problem somewhere with CTools integration (the problem starts with registry_update() and crashes during ctools_registry_files_alter()), and also crashes the same with both PHP 5.2 and 5.3.

recidive’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #4 works for me.

pbuyle’s picture

I've the same issue when running several test cases using the Media module. In my case, the stacktrace looks like

media_type_get_types
[...]
file_entity_entity_info_alter
[...]
entity_views_data
[...]
entity_views_plugins
views_discover_plugins
[...]
media_views_default_views
_ctools_export_get_defaults
ctools_export_load_object
ctools_export_crud_load_all
views_get_all_views
views_get_enabled_views
media_media_browser_plugin_info
[...]
ctools_get_plugins
[...]
registry_update
module_enable
DrupalWebTestCase->setUp
MyTestCase->setUp
DrupalTestCase->run
[...]

It doesn't happen when installing a profile, so the patch in #4 doesn't work.

pbuyle’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
890 bytes

The attached patch checks if the {media_type} table exist before querying it. It defaults the static $types variable to an empty array instead of the (default) NULL value but since the array is implicitly casted to a boolean in the if statement, it shouldn't have any other side effect than ensuring that the returned value is an array.

pbuyle’s picture

There is a typo in my patch in #12, here is a the fixed version.

emptyvoid’s picture

Sadly this patch didn't fix the problem. Even with the patch applied I still get a PDO sql error when attempting to install it.

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'pressflow7-base.media_type' doesn't exist: SELECT mt.* FROM {media_type} mt ORDER BY weight ASC; Array ( ) in media_type_get_types() (line 128 of /srv/distributions/pressflow7/code/sites/all/modules/contrib/media/includes/media.types.inc).

I setup a clean build of Drupal and attempted to debug the install process using xdebug, the hook_install function doesn't appear to ever get called during install!

Is there an alternative module that will allow me to leverage the media_{CDN_name} support modules?
In the past the modules for CDN integration were setup to work with a CCK field. Now I'm forced to have to use this module, which has never worked for me on Drupal or Pressflow 7.

Linux: Ubuntu 11
Apache 2
php 5.3.2
mysql 5.1
Drupal: 7.9

Also, I have read a few moderators who have setup a fresh build of Drupal and the media module stating that it installed with no problems. When doing so did you also install all of the dependent modules to truly test it?

When considering a test-case I would assume you also installed:

wysiwyg_api
ckeditor

And setup an input format to use the editor, then bring up the media browser to add a new image.

Even with the error during install (PDO SQL) the module was enabled.. and the media browser appears in the wysiwyg editor. However, attempting to upload, browse, or download from a CDN results in modal dialog failing.

:( sad camper, here. I haven't been able to track down why the install just doesn't work.

emptyvoid’s picture

Although I don't have an answer to why it is not installing, yet. I do have a few clues based on my debugging.

The issue appears to resolve around the hook_schema_alter() where multiple modules modify the media schema prior to it being created for the first time. I have found the following modules (core) and (contrib) where causing issues during the install process. Disabling the modules allowed for the install process to progress further. However I still haven't got the schema to be built.

- rdf (core)
- admin_menu (contrib)

both modules were causing the install process to error out prior to calling the hook_schema_alter() in core.

I'll post more as I find out more, although I'm convinced the issue is about how the media.install is written more than the conflicts. But only time will tell.

emptyvoid’s picture

Ok I sort of got the "fresh" install to work on a new version of Drupal/Pressflow 7.4

1) enable module (get PDO) error
2) with the Devel module enabled go to the "execute php" page and enter: drupal_install_schema('media');
3) Clear cache, run cron, run update.
4) disable media
5) enable media (it will then grok because it attempts to add the tables but it already exists!)
6) Clear cache, run cron, run update (not I saw no update changes, just ran it to be sure)

Now when I go to add a page in the wysiwyg editor the media button appears and I can successfully add media.

Sadly now in the media dialog I get:

    Notice: Undefined index: #file in theme_media_thumbnail() (line 245 of /srv/distributions/pressflow7/code/sites/all/modules/contrib/media/includes/media.theme.inc).
    Notice: Trying to get property of non-object in theme_media_thumbnail() (line 245 of /srv/distributions/pressflow7/code/sites/all/modules/contrib/media/includes/media.theme.inc).
    Notice: Undefined index: #file in theme_media_thumbnail() (line 245 of /srv/distributions/pressflow7/code/sites/all/modules/contrib/media/includes/media.theme.inc).
    Notice: Trying to get property of non-object in theme_media_thumbnail() (line 245 of /srv/distributions/pressflow7/code/sites/all/modules/contrib/media/includes/media.theme.inc).

pbuyle’s picture

@emptyvoid Check that the patch is applied properly. The patch guard the query with a db_table_exists('media_type'). Unless db_table_exists lies, a "Base table or view not found" could not happen here once the patch is properly applied. The "Undefined index: #file" error are a different and separated issue and may be linked to #1270036: File Entity breaks the array output of the file field default formatter.

adamdicarlo’s picture

Patch #13 fixes installation of Media during an install profile for me.

@DamienMcKenna what's happening during the hook_registry_alter() is that CTools asks for Media's plugins, and Media in turn asks Views for all enabled views (function media_media_browser_plugin_info()) which in turn leads to Views asking CTools for ... something, which ends up calling media_type_get_types() which explodes.

So perhaps a somewhat less hacky approach would be to bail out of media_media_browser_plugin_info() before

  // Add a plugin for each View display using the 'media_browser' display type.
  foreach (views_get_enabled_views() as $view) {

if Media's installation is in progress.

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs review

Sounds like this is not quite RTBC then.

emptyvoid’s picture

Status: Reviewed & tested by the community » Needs review

Update, I wasn't able to install the media module on an existing build. A fresh install with the 7.x-2.x-dev gave me no joy.

I reverted to the 7.x-1.x-dev release and did a fresh install with no other modules enabled. Then installed the media/entity modules and no errors were triggered during install. :)

I'll build a full module/feature set and see how the 1.x branch holds up. But I'd like to take advantage of the 2.x branch someday.

pontus_nilsson’s picture

I can also confirm that Patch #13 fixes the problem with Base table or view not found: 1146 Table 'database.media_type' doesn't exist during installation from an installation profile.

LIQUID VISUAL’s picture

Thank you for #13 above!!

This patch enabled installation of OpenOutreach profile whereas without this patch there were several errors after installation.

Anonymous’s picture

Patch #13 works for me on install, but it gives me the following error after installing a feature that uses Media.

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd7vmdohcom.media_filter_usage' doesn't exist: DELETE FROM {media_filter_usage} WHERE (timestamp < :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 1312856331 ) in media_flush_caches() (line 973 of /var/aegir/platforms/vmdoh_standard-7.10/sites/all/modules/media/media.module).

pbuyle’s picture

@Brian This is a different, and likely unrelated, issue (different table, happens after installing) so it should be reported a a separated issue.

acare’s picture

Hi, bit confused as this is my first Drupal install.
1. There was no includes/media.types.inc (I created it and manually applied the patch)
2. The underlying table is also missing
3. it still errors

Can I create the table, I looked but there is no schema in the documentation I could find?

Or is it best to delete everything, and reinstall. But will the table appear next time?

GUY

nedjo’s picture

Status: Needs review » Needs work
FileSize
115.69 KB

Here's a full backtrace for one instance of this error, which occurs when installing the Open Outreach distro.

It would seem unreasonable to expect that every hook implementation should test to ensure its module's tables are in place in case it's incorrectly invoked by another module before it's completed installation. So hook_file_type_info() doesn't feel like the right place to fix this. But it's not straightforward to identify just what the culprit is here from amidst this complex nesting of calls by numerous modules. Our challenge seems to be to identify where the onus or responsibility lies to address the potential for stray invocations.

From an initial scan of the backtrace, one call that stands out is advanced_forum's call to taxonomy_vocabulary_load() in its hook_views_default_views() implementation, which triggers entity info loading, altering, and eventually file type info loading. Perhaps the onus to address/avoid premature data calls should be on modules invoking API calls from within default hook implementations. But of course this particular call in advanced_forum is only one potential source of this error.

exratione’s picture

When setting up a profile installation with many modules, I had much the same issues here with a range of ctools-touching modules and others. Schema being accessed during module installation in module_enable() before the schema was created.

I'm attaching a patch that solved these problems for me - basically move the calls to registry_update() and drupal_get_schema() inside module_enable() to happen after the schema is put in place in that function call. Which may of course upset something in your world, but I'm finding it's good so far.

nedjo’s picture

Status: Needs work » Needs review
FileSize
2.51 KB

Looked at this more and adamdicarlo's suggestion in #18 looks correct. But rather than testing just for media being in the process of installation, we need to test for any module being installed.

Ctools loads plugin info as part of determining how the registry should be altered, a task that's invoked from module_enable() when a module's .module file has been loaded but before its schema has been installed. So in media_media_browser_plugin_info() calling views_get_enabled_views() while a module (not just Media) is being installed could trigger could prematurely invoke the module's hook implementations.

Attached patch uses the presence of the drupal_load_updates() function from install.inc as as a proxy test for installation tasks. We can't use drupal_installation_attempted() because we need to detect module installation after Drupal has been installed.

On my testing, this fixes fatal errors I was hitting during install not only in media but also in profile2, see #1307538: Unable to install Profile 2 from an installation profile..

rgristroph’s picture

I ran into this issue with an install profile, and I can confirm that the patch in #28 fixed it, allowing me to complete the installation. I also read through the code involved, and the patch looks good, but I am completely unfamiliar with the code, so take that only for what it's worth.

Thanks to everyone who worked on this issue - I was thrashing about pretty unproductively until I found this issue and patch -- thanks guys.

--Rob

othermachines’s picture

Also ran across this error while running an installation profile. Patch in #28 solved it. Thanks!

acare’s picture

Hi again,
Got ready to do the patch on Windows but I still cannot determine which file to patch, media.module is not a part of my 7.10 installation.

Please give me a file path

Thanks

jherencia’s picture

#28 worked for me, too.

acare’s picture

Did a fresh download and install which also works

fabsor’s picture

Status: Needs review » Reviewed & tested by the community

We have been running with #28 for quite some time in NodeStream, and we have not experienced any problems with it. With that in mind + the positive comments below, I think we can set this to RTBC.

Dave Reid’s picture

I'm working on converting the media browser plugins to not use the CTools plugin system because it ends up with weird crap like this.

jensimmons’s picture

I ran into this same problem. New Drupal install. On Pantheon. No content or fields exist yet. Turned on Media 1. Upgrading to Media 2. Views and CTools are present, on, and up to date. Running update.php to upgrade Media throws errors.

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'pantheon.views_view' doesn't exist: SELECT t__0.* FROM {views_view} t__0; Array ( ) in ctools_export_load_object() (line 427 of [mysite]/code/sites/all/modules/ctools/includes/export.inc).

;( This patch is not helping. Crap.

Dave Reid’s picture

The table name is different - doesn't seem related to this issue which is about the {media_type} table?

cinseattle’s picture

Dave Reid’s picture

Status: Reviewed & tested by the community » Fixed

This should now be resolved with the patch committed in #1400200: Clean up browser plugins that no longer relies on using CTools for Media browser plugins.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

faravision’s picture

I am a newbie to Drupal and am working on a locally hosted site using bitnami drupal stack. As I was downloading and enabling a media module I got the following error message

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'bitnami_drupal7.media_type' doesn't exist: SELECT mt.* FROM {media_type} mt ORDER BY weight ASC; Array ( ) in media_type_get_types() (line 134 of C:\Program Files\BitNami Drupal Stack\apps\drupal\htdocs\sites\all\modules\media\includes\media.types.inc).

I would not know where to start how to fix this issue. I was using a Zen theme and now I can no longer view my homepage and I keep getting the error above. All I view is my website logo and the error message. Your advice is greatly appreciated.

Thanks.

FAra

exratione’s picture

Later version of patch in #27 attached. Works great for us, solves the same problem where it crops up in other modules. Appears to have limited or no side-effects.

jcallanan’s picture

I'm getting this error as well with the Open Atrium 2 distro. Were you able to find a solution?

bwoods’s picture

I ran into the same issue with OA. I ran the sql to add media_type, and it seemed to work. I found the sql statement here - http://pastebin.com/cf4bBjjE .

bwoods’s picture

Issue summary: View changes

Updated issue summary.

khayam shah’s picture

i am facing this error

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'openatrium.search_api_server' doesn't exist

please guide me about this

jordan8037310’s picture

Thanks for the SQL to add media_type, bwoods!

bdupls’s picture

I used SQL create table from bwoods post only not the patch since the patch dates back 4 years surely it is included in latest media module.
Just doing create table I still get error, when I try and clear cache.
WD registry: PDOException: SQLSTATE[42S02]: Base table or view not [error]
found: 1146 Table 'xxx.media_type' doesn't exist:
SELECT mt.*
FROM
{media_type} mt
ORDER BY weight ASC; Array
(
)
in media_type_get_types() (line 134 of
/home/xxx/public_html/sites/all/modules/contrib/media/includes/media.types.inc).
SQLSTATE[42S02]: Base table or view not found: 1146 Table [error]
'xxx.media_type' doesn't exist

Running Drupal Commons 7.x3.26

After resetting apache I go this error. I seem to be running from one error to the next.

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxx.shortcut_set' doesn't exist: SELECT s.set_name AS set_name FROM {shortcut_set} s INNER JOIN {shortcut_set_users} u ON s.set_name = u.set_name WHERE (u.uid = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 1 ) in shortcut_current_displayed_set() (line 497 of /home/xxx/public_html/modules/shortcut/shortcut.module).

Alex Oliver Perez’s picture

#44 fix the errors. Thanks a lot bwoods for the link http://pastebin.com/cf4bBjjE.

I added back the media_type manually by using the script and the errors are gone. Tested the media and its back to normal again.

CREATE TABLE `media_type` (
`name` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'The machine name of the media type.',
`label` VARCHAR(255) NOT NULL DEFAULT '' COMMENT 'The label of the media type.',
`base` tinyint(4) NOT NULL DEFAULT '0' COMMENT 'If this is a base type (i.e. cannot be deleted)',
`weight` INT(11) NOT NULL DEFAULT '0' COMMENT 'Weight of media type. Determines which one wins when claiming a piece of media (first wins)',
`type_callback` VARCHAR(255) DEFAULT '' COMMENT 'Callback to determine if provided media is of this type.',
`type_callback_args` longtext COMMENT 'A serialized array of name value pairs that will be passed to the callback function',
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Stores the settings for media types.';

------------------

INSERT INTO `media_type` (`name`, `label`, `base`, `weight`, `type_callback`, `type_callback_args`) VALUES
('audio', 'Audio', 1, 0, 'media_is_type', 'a:4:{s:10:"match_type";s:3:"all";s:9:"mimetypes";a:1:{i:0;s:8:"/^audio/";}s:10:"extensions";a:3:{i:0;s:3:"mp3";i:1;s:3:"ogg";i:2;s:3:"wma";}s:7:"streams";a:2:{i:0;s:6:"public";i:1;s:7:"private";}}'),
('default', 'Other', 1, 1000, 'media_is_type', 'a:2:{s:10:"match_type";s:3:"any";s:9:"mimetypes";a:1:{i:0;s:4:"/.*/";}}'),
('image', 'Image', 1, 0, 'media_is_type', 'a:4:{s:10:"match_type";s:3:"all";s:9:"mimetypes";a:1:{i:0;s:8:"/^image/";}s:10:"extensions";a:5:{i:0;s:3:"jpg";i:1;s:4:"jpeg";i:2;s:3:"gif";i:3;s:3:"png";i:4;s:4:"tiff";}s:7:"streams";a:2:{i:0;s:6:"public";i:1;s:7:"private";}}'),
('video', 'Video', 1, 0, 'media_is_type', 'a:4:{s:10:"match_type";s:3:"all";s:9:"mimetypes";a:1:{i:0;s:8:"/^video/";}s:10:"extensions";a:3:{i:0;s:3:"mov";i:1;s:3:"mp4";i:2;s:3:"avi";}s:7:"streams";a:2:{i:0;s:6:"public";i:1;s:7:"private";}}');

Anonymous’s picture

#44 worked for me, thanks bwoods!