Schema API is not unit tested

As you said, it doesn't pass without the MySQL strict fix. However, IMHO the problem is not with the test but with the DB API.

What happens is that you start with:

   $table_specification = array(
      'fields' => array(
        'id'  => array(
          'type' => 'int',
          'not null' => TRUE,
          'default' => NULL,
        ),
        'test'  => array(
          'type' => 'int',
          'not null' => TRUE,
        ),
      ),
    );

but then when the table is created in MySQL, the NULL default on field "id" is not passed during creation. And you get a field "id" like "`test` int(11) NOT NULL", without a default, although the test requests a NULL default. This comes from DatabaseSchema_mysql->createFieldSql(), which tests for:

    if (isset($spec['default'])) {
      if (is_string($spec['default'])) {
        $spec['default'] = "'" . $spec['default'] . "'";
      }
      $sql .= ' DEFAULT ' . $spec['default'];
    }

which causes it to ignore NULL defaults. The problem could be removed by using something stricter like:

    if (array_key_exists('default', $spec)) {
      if (is_string($spec['default'])) {
        $spec['default'] = "'" . $spec['default'] . "'";
      } elseif (is_null($spec['default'])) {
        $spec['default'] = 'NULL';
      }
     
      $sql .= ' DEFAULT ' . $spec['default'];
    }

Now, if you use this, the table creation is simply rejected, and the test cannot proceed to the subsequent errors. OTOH, I suppose it may break other code elsewhere which uses such DDL, and which should probably be fixed.

The test itself, though, has another potential problem: if db_create_table fails, none of the subsequent tests can proceed, so it might make more sense to drop out of the test if the initial table creation fails. When testing interactively, this is not an issue, but since each test is costly, for automated testing it could make more sense to fail early than to let a full series of failure happen. But this is more a policy than a technical issue, and I'm not (yet ?) aware of the policy choices in that regard.

Out of sheer curiosity, why did you replace is_null($spec['default']) by !isset($spec['default']) ?

It seems to give the same result in this specific case, although it is maybe a bit harder to read because it is less specific; maybe it's a core style guide issue ?

This being said, i think it would also make sense to ask for that NULL default on non-NULL column, and make sure an error is indeed returned and the table is not created. It could make another case for the test.

Cleaned-up the schema API test (and only it), the fix for drivers should go in a different issue, IMO.

Fixed missing {} in the queries.

The fix for the MySQL implementation is now in a separate issue: #333499: Fix handling of NULL default values in MySQL schema API

Improved version: we now check that the previously inserted rows are kept when changing the definition of a field (this is useful because the SQLite implementation migrate the data to a new table because there is limited ALTER TABLE support on that engine).

Committed to CVS HEAD. Other test to follow soon.

@Dries: apparently you committed #10, not #12.

Here is a patch against HEAD.

Latest patch had a strange $Id$.

Thanks for the prompt help. Committed to CVS HEAD. Thanks.