Closed (fixed)
Project:
Schema
Version:
6.x-1.3
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Apr 2009 at 18:37 UTC
Updated:
24 May 2009 at 16:40 UTC
Jump to comment: Most recent file
Something somewhere is not quite drupal_set_active('default')ing the way it should. I get this upon submitting the form at admin/content/tw when adding a table from an external database:
# user warning: Table 'pug_backup.system' doesn't exist query: SELECT * FROM system WHERE type = 'theme' in /Users/webchick/Sites/pug/includes/theme.inc on line 449.
# notice: Undefined index: garland in /Users/webchick/Sites/pug/includes/theme.inc on line 59.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 92.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 219.
# user warning: Table 'pug_backup.cache' doesn't exist query: SELECT data, created, headers, expire, serialized FROM cache WHERE cid = 'theme_registry:' in /Users/webchick/Sites/pug/includes/cache.inc on line 26.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 418.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 418.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 418.
# notice: Trying to get property of non-object in /Users/webchick/Sites/pug/includes/theme.inc on line 235.
# user warning: Table 'pug_backup.cache' doesn't exist query: UPDATE cache SET data = '<snip>' WHERE cid = 'theme_registry:' in /Users/webchick/Sites/pug/includes/cache.inc on line 109.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | tw-db-set-active-424486-3.patch | 751 bytes | webchick |
Comments
Comment #1
mikeryanDid you see rowcounts when you did this? I committed the implementation of rowcounts, immediately realized I missed a db_set_active('default'), and fixed that within 2 minutes - maybe you did a cvs update in those 2 minutes? Looking at the db_set_active's in tw now, it looks like they always get set back to default...
Thanks.
Comment #2
webchickHm. Yep, this is with the latest, bleeding edge cvs up -dPC.
I'll try and do some debugging a bit later as an attempt to figure out where this is coming from. I realize it's hard to debug on your side without a copy of my data.
Comment #3
mikeryanJust reviewing db_set_active's:
In the Schema inspect functions, db_set_active() is immediately cancelled out by setting back to the original connection.
In tw_perform_analysis(), we set it back and forth, but set it to default at the end just to make sure - there are no returns within the function to short-circuit this.
In _tw_sources_form(), brand-new rowcount support sets the table's connection to get its rowcount, but following the loop it sets back to default.
tw_tw_form() sets each connection from $db_url, but always sets back to default.
Only the first two of these is called when adding tables (and tw_perform_analysis() calls the schema inspection)... Thinking about it some more, it looks like cache_set('theme_registry:') is being called, so something in tw_perform_analysis() must be triggering this. Actually, drupal_flush_all_caches() is called at the end of tw_add_tables(), that would do it - but tw_perform_analysis always sets back to default at the end.
I'm at a loss...
Comment #4
webchickHm. Well this fixes it. But I'm not sure that this is the right spot for this... seems like other stuff should be breaking too.
Comment #5
webchickHm. Weird. This is a very pesky bug to track down.
If I add one external table, it doesn't happen.
If I add two or three external tables, it doesn't happen.
If I add ALL of the tables, I get this error.
Patch doesn't make a difference. Hum..
Comment #6
webchickHahaha. Oh, this is quite literally CRAZY! ;) http://www.lullabot.com/articles/quick_and_dirty_debugging to the rescue!
Remember back in #424470: "no Schema type for mysql type enum/timestamp" how I was getting error messages from Schema module about how enum and timestamp aren't valid column types? And also that I'm importing data from an external database?
Well!
It turns out, that the first of those error message calls theme('placeholder') thanks to %table and %fieldname in the string. The very first thing theme() does is call init_theme(), since the theme system hasn't been initialized yet on this request. That will query the system table to get a list of themes (the first query that fails), not find anything since the system table doesn't exist in my external database, and then it's all downhill from there.
So, uh... I'm not really sure what you can do about this problem, but at least we know what causes it. ;) I guess one fix is to change % to @ in the schema.module message so that it's not initializing the theme system too early. Any other ideas?
Comment #7
webchickIn other words, steps to reproduce:
1. Create a database called "external"
2. Import the following table into it: (doesn't have to be this one; anything with enum or timestamp columns will do):
3. Change your $db_url in settings.php from:
to:
4. Go to admin/content/tw and add the external.cms_cpg_albums table.
5. Bask in the warm glow from sheets of flaming red errors.
Comment #8
webchickFixing title to be more descriptive.
Comment #9
mikeryanHmmm... A possible solution would be to modify my schema module patch to take connection name as an optional parameter and do the db_set_active() itself before calling db_query (setting it back after the db_query()). I think once the result is returned, the active connection won't matter to db_fetch_array...
Comment #10
mikeryanThe schema module needs to be sure it's got the default connection before issuing errors.
Comment #11
mikeryanI took the patch of least resistance - @ instead of % for schema type errors.