We need to allow the database driver to perform updates on a database to be able to create/manage metadata. This is needed for #998898: Make sure that the identifiers are not more the 63 characters on PostgreSQL.

Context: For the issue mentioned above, we need a database table containing driver-specific data (in this case a list of created indexes/keys together with a short (less than 63 characters) name). These metadata need to be contained within the database abstraction layer (otherwise, how would it be an abstraction?), and thus we need to be able to create such table from within the database layer.

Here's a first go at it.

Comments

Status: Needs review » Needs work

The last submitted patch, allow-db-driver-updates.patch, failed testing.

Stevel’s picture

Status: Needs work » Needs review
StatusFileSize
new7.94 KB

Let's try again, tested locally now...

Status: Needs review » Needs work

The last submitted patch, allow-db-driver-updates-without-undefined-method-calls.patch, failed testing.

Stevel’s picture

Status: Needs work » Needs review

#2: allow-db-driver-updates-without-undefined-method-calls.patch queued for re-testing.

edit: failing tests pass locally...

Status: Needs review » Needs work

The last submitted patch, allow-db-driver-updates-without-undefined-method-calls.patch, failed testing.

Stevel’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, allow-db-driver-updates-without-undefined-method-calls.patch, failed testing.

Stevel’s picture

Status: Needs work » Needs review
StatusFileSize
new7.83 KB

Patch didn't apply any more. Rerolling

steven jones’s picture

Guess there's no way to leverage a normal module for this, and the existing update mechanism?

Stevel’s picture

That's exactly what we're trying to avoid. Of course it's possible to put some if ($driver == 'pgsql') then do this or that in system_update_N, but that would be like (ab)using system.install for all of core update code and use if module_installed($module) then update it. We want to keep driver-specific updates inside the driver it belongs.

steven jones’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs review » Needs work

I've been thinking about this approach and I'm not a fan, basically you're making the database drivers more of a framework in their own right, by adding updates to them. Currently the DB layer is used as pretty much just an abstraction layer between Drupal and the DB, all the logic of which tables have been created are kept in Drupal, not the DB layer. I think it's okay to have normal Drupal updates doing DB updates, and I don't think we need a separate mechanism for this in Drupal just for the DB drivers.

I would encourage you to mark this as 'Closed (won't fix)'

skhot’s picture

I have a dev site that was planning to go to production soon, when all of the sudden (likely from updating modules and core), we started getting these kinds of errors:

PDOException: SQLSTATE[23000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot insert duplicate key row in object 'dbo.file_managed' with unique index 'uri_unique'. in drupal_write_record() (line 6776 of E:\content\includes\common.inc).

PDOException: SQLSTATE[23000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Cannot insert duplicate key row in object 'dbo.block' with unique index 'tmd_unique'. in drupal_write_record() (line 6859 of E:\content\includes\common.inc).

PDOException: SQLSTATE[42S02]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Invalid object name 'shib_auth'.: SELECT * FROM {shib_auth}; Array ( ) in _shib_auth_list_rules() (line 101 of E:\content\sites\all\modules\shib_auth\shib_auth_roles_forms.inc).

I suspect that these errors are due to no way to properly update the schema structure between the different versions of the database driver (http://drupal.org/node/1161664#comment-4540872). We are using Microsoft SQL Server 10.50.1600 and Microsoft-IIS/7.5 with Drupal 7 driver for SQL Server and SQL Azure. Any advice on how to overcome this problem?

cweagans’s picture

Status: Needs work » Closed (won't fix)

Yeah, this is definitely a won't fix. The database layer should just be an intermediary between the business logic and the data store.

As for #12, my advice to you is simply "Don't use MSSQL", which may or may not be an option at this point.