I've a problem with schema_mysql.inc,v 2008/02/16, from the 5.x-1.1 release. There in function schema_mysql_inspect can be found:

// Ignore tables not in Drupal's schema.
if (!isset($schema[$r['TABLE_NAME']])) {

But this is no good. I try to port the spam module to schema and I could'nt get proper schema output with the schema inspect:

warning: Invalid argument supplied for foreach() in /home/milian/projects/drupal-5.7/modules/schema/schema.module on line 25.

This is because of the above mentioned part. Output here is for example:

['spam_filters_errors'] = array(
'fields' => array(
'primary key' => array('bid'),
'unique keys' => array(
'content_hash' => array('content_hash'),
'content_id' => array('content_id', 'content_type')),
'indexes' => array(
'content_hash_2' => array('content_hash'),
'content_type' => array('content_type'),
'hostname' => array('hostname'),
'timestamp' => array('timestamp')),

The fields are missing obviously. If I remove the above mentioned code from schema_mysql.inc it works properly! But the comment tells me, that there seem to be other issues involved.


Version:5.x-1.1» 6.x-1.2

Still an issue in 6.x-1.2, although that specific line is gone. It seems like this is reducing the usefulness of this module as a tool for auto-generating schema arrays... and the text on the Inspect tab:

"To implement hook_schema() for a module that has existing tables, copy the schema structure for those tables directly into the module's hook_schema() and return $schema."

...seems to imply this is how it's intended to work.

The workflow I was hoping for:
1. Create the table I want in PHPMyAdmin or from the command line.
2. Go to admin/build/schema/inspect
3. Copy/paste schema definition into my module's hook_schema().

Well, this is a bit of a dilemma (or, rather, a trilemma).

Suppose a table exists in the database that is not in Drupal's schema, and suppose further that it contains a column whose data type (e.g. YEAR) does not map to any Schema data type. When inspecting and trying to generate a schema structure for the table, schema.module has three options for what to do:

1. Generate a warning ("No Schema type for MySQL data type /YEAR/") and output a partially-correct schema structure. This was schema.module's original behavior. In http://drupal.org/node/202385, I got complaints because the Drupal database contained tables that did not belong to Drupal and it was okay that they had non-Drupal data types, but schema.module was generating a ton of warnings anyway.

2. Simply ignore tables in the database that are not in Drupal's schema. This way, any non-Drupal table with random column data types will not cause "spurious" warnings. This was my response to issue #202385 but clearly it was a mistake because it kills a major benefit of the inspection code: the ability to generate schema structures for existing tables.

3. Stop ignoring tables that are not in Drupal's schema (reverting to the original behavior in this regard) but do NOT generate warnings for data types that are inspected from the database. This way, schema structures are generated for new tables that people want to port to D6, but no "spurious" warnings are generated for non-Drupal tables that happen to be in the database. Unfortunately, this is also a really bad idea because it means that schema.module will be SILENTLY generating invalid schema structures that, when copied into a hook_schema(), will not work.

I think the correct behavior is what I had originally and that issue #202385 should have been marked "won't fix".

I guess, in the specific case of #202385, if Drupal is using a database prefix, I can ignore any table that does not have that prefix as it is clearly a non-Drupal table. Right?

No, if Drupal is using a database prefix, I cannot ignore any table that does not have that prefix as a non-Drupal table. Suppose a site is using this prefix array:

= array(
'users' => 'shared_',
'default' => '',

There is no way to identify unrecogized tables as "belonging to a Drupal module that has not yet created its hook_schema()" vs. "not belonging to Drupal."

If $db_prefix is set to a string I could make this determination but I'm not willing to make a partial solution like that.

I think I am convinced that #202385 should never have been "fixed" and that I should simply back out the change. I'll ponder it a bit more, though.

Status:Active» Fixed

Status:Fixed» Closed (fixed)

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

very cool module. thank you for it.

I just installed Schema 5.x-1.1 and experienced the same exact problem as described by the original author of this thread. Removing the offending lines as shown fixed this issue.

Thanks for an otherwise excellent module.