Need to reset module_list()
| Project: | SimpleTest |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | boombatower |
| Status: | closed |
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.
#1
The test in question is totally empty, so I guess the problem is in some implicit setup.
#2
This appears to be caused by og.install:
<?php
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?
#3
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
#4
#5
Complete backport of Drupal 7.x SimpleTest module. (voids all backports). (SimpleTest 2.6)
Please re-open if still an issue.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.
#7
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.
#8
Still an issue... :(
#9
Any thoughts on how to fix? Sounds like static issue?
#10
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:
<?phpif (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.
#11
If I just enable 'og', it also causes Views to be invoked, causing a similar error. FYI og_install does:
<?php
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:
<?phpforeach (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?!?
#12
This was on D7: fresh install from this morning's CVS. This was running Simpletest on the Coder module.
#13
I'm getting what looks like the same warning with the current DRUPAL-6--2 checkout:
#14
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.
#15
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.
#16
Trying it out. nick.dap if it works, I will find you and give you a hug.
#17
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.
#18
Then this should be completed in core and backported.
#19
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.
#20
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
#21
(subscribing)
fix from #15 does not work for me
fix mentioned in #20 does not work for me
#22
#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
#23
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:
<?phpparent::setUp('book', 'views', 'content', 'text', 'number', 'optionwidgets', 'nodereference', 'relativity', 'myModule');
?>
We got it to work by replacing it with:
<?phpparent::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.
#24
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.
#25
@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!
#26
Did you read the docs page I linked to? I can't really elaborate until I know where your knowledge level is.
#27
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.
#28
Latest backport includes the cheesy commit from D7 so should be fixed.
#29
Also see #375931: Simpletests are broken when cvs_deploy is enabled
#30
I do use CVS Deploy.
#31
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.
#32
Automatically closed -- issue fixed for 2 weeks with no activity.