With simpletest 6.x-2.x-dev, this happens even with the tests provided with OG:

Table 'drupal6.simpletest400428imagecache_preset' doesn't exist query: SELECT * FROM simpletest400428imagecache_preset ORDER BY presetname	User warning	database.mysqli.inc	128	_db_query()	
Table 'drupal6.simpletest400428lm_paypal_subscriptions' doesn't exist query: SELECT subid, item_name, status FROM simpletest400428lm_paypal_subscriptions WHERE status = 1 AND (kind = 0 OR kind = 2)	User warning	database.mysqli.inc	128	_db_query()	
Table 'drupal6.simpletest400428views_view' doesn't exist query: SELECT DISTINCT v.* FROM simpletest400428views_view v	User warning	database.mysqli.inc	128	_db_query()	
Table 'drupal6.simpletest400428cache_views' doesn't exist query: SELECT data, created, headers, expire, serialized FROM simpletest400428cache_views WHERE cid = 'views_default_views:en'	User warning	database.mysqli.inc	128	_db_query()	
Table 'drupal6.simpletest400428cache_views' doesn't exist query: UPDATE simpletest400428cache_views SET data = 'a:7:{s:15:\"comments_recent\";O:4:\"view\":23:{s:8:\"db_table\";s:10:\"views_view\";s:10:\"base_table\";s:8:\"comments\";s:5:\"built\";b...
update\";s:11:\"date_format\";s:5:\"large\";s:18:\"custom_date_format\";s:0:\"\";s:7:\"exclude\	User warning	database.mysqli.inc	128	_db_query()

Yes, that looks like my "host" configuration is leaking into the tests somehow. No idea why! This doesn't happen for my other modules.

CommentFileSizeAuthor
#15 seeping_module_list_fix.patch806 bytesnick.dap
#2 php_error.txt2.79 KBlyricnz
#1 testog.test757 byteslyricnz

Comments

lyricnz’s picture

lyricnz commented
StatusFileSize
new testog.test757 bytes

The test in question is totally empty, so I guess the problem is in some implicit setup.

lyricnz’s picture

lyricnz commented
Project: SimpleTest » Organic Groups
Version: 6.x-2.x-dev » 6.x-1.1
Component: Code » og.module
StatusFileSize
new php_error.txt2.79 KB

This appears to be caused by og.install:

function og_install() {
  drupal_install_schema('og');

  // enable standard og blocks. for custom profiles, block may not be included yet.
  if (function_exists('_block_rehash')) {
    _block_rehash();
  }
  ...

The function _block_rehash() calls hook_block($op='list) for all enabled modules *before* their own .install files are run (and the database tables are created).

Attached log emits module_load_install() when a module is installed, and FOO when _block_rehash() calls hook_block($op='list'). See how it's calling this method on modules that haven't been enabled?

lyricnz’s picture

lyricnz commented
Project: Organic Groups » SimpleTest
Version: 6.x-1.1 » 6.x-2.x-dev
Component: og.module » Code

This seems to be the simpletest "host" environment leaking into the sandbox a little? If I disable those modules in my drupal install, then the warnings go away. Hmm.... reassigning to SimpleTest

moshe weitzman’s picture

moshe weitzman commented
Title: Enabling "og" module in simpletest produces warnings » Simpletest environment problem -table not available.
Project: Organic Groups » SimpleTest
Version: 6.x-1.1 » 6.x-2.x-dev
Component: og.module » Code
boombatower’s picture

boombatower commented
Assigned: Unassigned » boombatower
Status: Active » Fixed

Complete backport of Drupal 7.x SimpleTest module. (voids all backports). (SimpleTest 2.6)

Please re-open if still an issue.

Status: Fixed » Closed (fixed)

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

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Using latest Simpletest 6.x-2.x-CVS, I still get n exceptions about cache_update doesn't exist. Once I visited admin/reports/updates, it went away, but the problem still appears to persist in the latest version. If I see it happen again, I will reopen the issue. Leaving closed for now.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Closed (fixed) » Active

Still an issue... :(

boombatower’s picture

boombatower commented
Status: Active » Postponed (maintainer needs more info)

Any thoughts on how to fix? Sounds like static issue?

lyricnz’s picture

lyricnz commented

I don't know if this is representative, but I made a test that did just parent::setUp('content', 'text') in it's setUp() method, and it gets the following warnings:

Table 'drupal6.simpletest783932date_format_types' doesn't exist query: SELECT dft.type, dft.title, dft.locked FROM simpletest783932date_format_types dft ORDER BY dft.title	User warning	database.mysqli.inc	128	_db_query()	
Table 'drupal6.simpletest783932cache_views' doesn't exist query: DELETE FROM simpletest783932cache_views	User warning	database.mysqli.inc	128	_db_query()

Adding some debugging to the mysql code, the backtrace to the warning actually comes:

includes/database.mysql-common.inc:42 _db_query()
includes/cache.inc:172 db_query()
sites/all/modules/views/views.module:407 cache_clear_all()
sites/all/modules/cck/content.module:1543 views_invalidate_cache()
sites/all/modules/cck/content.module:551 content_clear_type_cache()
...

Views?!? But I didn't ask for this module to be enabled. Looking at content_clear_type_cache() it says:

  if (module_exists('views')) {
    // Needed because this can be called from .install files
    module_load_include('module', 'views');
    views_invalidate_cache();
  }

Hmmm... So modules are explicitly including each other, based on module_exists() - which seems to find the module if the simpletest _host_ has it, not the test environment. I'll try some different modules now, see if it's the same kind of problem.

lyricnz’s picture

lyricnz commented

If I just enable 'og', it also causes Views to be invoked, causing a similar error. FYI og_install does:

function og_install() {
  drupal_install_schema('og');

  // enable standard og blocks. for custom profiles, block may not be included yet.
  if (function_exists('_block_rehash')) {
    _block_rehash();
  }
...

and _block_rehash() does:

  foreach (module_list() as $module) {
    $module_blocks = module_invoke($module, 'block', 'list');

Which calls views_block(). So, it looks like again that module_list() is returning "views" when it probably shouldn't?!?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

This was on D7: fresh install from this morning's CVS. This was running Simpletest on the Coder module.

An error occurred.

Path: /batch?id=3&op=do
Message: PDOException: SELECT data, created, expire, serialized FROM {cache_update} WHERE cid = :cid -
Array
(
[:cid] => update_available_releases
)
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd7.simpletest389507cache_update' doesn't exist in _update_cache_get() (line 574 of C:\www\webapps\drupal-7\modules\update\update.module).

drewish’s picture

drewish commented
Status: Postponed (maintainer needs more info) » Active

I'm getting what looks like the same warning with the current DRUPAL-6--2 checkout:

Table 'd6.simpletest732990cache_update' doesn't exist query: SELECT data, created, headers, expire, serialized FROM simpletest732990cache_update WHERE cid = 'update_info'
User warning database.mysqli.inc 128 _db_query()

nick.dap’s picture

nick.dap commented

Still a problem with Drupal 6.12

I get this when running tests from the latest CCK [2.2].
I get this only when Views [2.5] is enabled in the host environment.

nick.dap’s picture

nick.dap commented
Status: Active » Needs review
StatusFileSize
new seeping_module_list_fix.patch806 bytes

Both lyricnz and boombatower are correct.

Some modules will include files based on module_exists, and rightfully so, as part of their install process. The problem is actually quite a bit larger and might have other consequences.

In the setUp function of DrupalWebTestCase we create a sandbox by calling drupal_install_module with a list of modules. However (and this might be a core bug as well) drupal_install_modules never refreshes the list of installed modules before calling the install functions on modules that we want installed. In other words, we end up using the 'static' version of the module list from our _host_ environment during the setUp process.

The fix is simple, call module_list(TRUE) which will force a refresh of the module list before calling drupal_install_modules.

Attached is the patch against the DRUPAL-6--2-8 release. Did it for me.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Trying it out. nick.dap if it works, I will find you and give you a hug.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Title: Simpletest environment problem -table not available. » Need to reset module_list()

This has an existing D7 issue in #440824: Reset module_list() and module_implements() on test setup. and marked #440836: Error when installation uses module_exists() as a duplicate of this bug.

boombatower’s picture

boombatower commented
Status: Needs review » Postponed

Then this should be completed in core and backported.

boombatower’s picture

boombatower commented

Try out: #472684: Install non-default modules one at a time to ensure proper module list is maintained during installation hooks I think it is the parent bug.

lyricnz’s picture

lyricnz commented

boombatower: the patch at #14 in #472684: Install non-default modules one at a time to ensure proper module list is maintained during installation hooks fixes the problem for me

soxofaan’s picture

soxofaan commented

(subscribing)

fix from #15 does not work for me
fix mentioned in #20 does not work for me

kenorb’s picture

kenorb commented

#15:
module_list(TRUE) shouldn't be called, it could cause other problems.
See: #496198: module_list() called with wrong arguments causing WSOD and breaking theme_registry

svdoord’s picture

svdoord commented

After days of pulling hairs (I even got a couple of grey ones), we finally figured out how to solve this in our situation. We use a number of optional and third-party modules in our tests, so our setUp had this line:

    parent::setUp('book', 'views', 'content', 'text', 'number', 'optionwidgets', 'nodereference', 'relativity', 'myModule');

We got it to work by replacing it with:

    parent::setUp();
    drupal_install_modules(array('book'));
    drupal_install_modules(array('views'));
    drupal_install_modules(array('content'));
    drupal_install_modules(array('text'));
    drupal_install_modules(array('number'));
    drupal_install_modules(array('optionwidgets'));
    drupal_install_modules(array('nodereference'));
    drupal_install_modules(array('relativity'));
    drupal_install_modules(array('myModule'));

We hope this will also help others with the problem.

moshe weitzman’s picture

moshe weitzman commented

thats not the same thing at all. setup installs modules in the tested site. your code installs modules in the testing side. the tested side is the one that is created by simpletetest at beginning of each test run and deleted shortly thereafter. see http://drupal.org/simpletest

there is a real problem here. i think schema api is not properly flushed but am not sure.

svdoord’s picture

svdoord commented

@moshe: I don't really understand what you're trying to say. My point is that we got exactly the same errors as described in this issue. Changing the order of the tests changed the results, but always exceptions remained. At first, it seemed that the patch in http://drupal.org/node/472684#comment-1631806 fixed our situation, but other strange things happened (the 'page' and 'story' content types didn't exist in the test anymore).

Our work-around fixed the exceptions. We wanted to post it somewhere, so that others may benefit from it. If this issue was not the correct one, I apologize for the confusion!

moshe weitzman’s picture

moshe weitzman commented

Did you read the docs page I linked to? I can't really elaborate until I know where your knowledge level is.

svdoord’s picture

svdoord commented

I did read them. I have used simpletest for several projects before, always without any difficulty. I've written some pretty advanced (project specific) Drupal modules.

Just to be sure: the code snippets I posted in #23 are two alternative implementations of the setUp() function (I probably should have included the "function setUp()" line as well). The first one gives the same type of errors as mentioned by the creator of this issue, the second implementation works as desired. Since parent::setUp() has already been called, drupal_install_modules installs them in the tested side, as the simpletest db table prefix has been set during parent::setUp. I confirmed the results by looking at the simpletest-prefixed database tables that are indeed created for all modules.

boombatower’s picture

boombatower commented
Status: Postponed » Fixed

Latest backport includes the cheesy commit from D7 so should be fixed.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Also see #375931: Simpletests are broken when cvs_deploy is enabled

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

I do use CVS Deploy.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Actually it wasn't a bug with CVS deploy, it was a bug with core's system.install, so it's more than likely the same problem you're getting NancyDru.

Status: Fixed » Closed (fixed)

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