A mysql database connection is serialized by cloning the current object; removing the connection, schema and driverClasses to save space; serializing the result; and destroying the cloned stripped down object. When the object is destroyed mysql deconstructor will call nextIdDelete() to cleanup the sequences table but now that the object doesn't have a connection the attempt fails and results in an error.

There's already some special handling around this code for the testing case where the connection object is mocked. As a quick fix I've added in some additional code to check for the case where it's just not set at all but this doesn't seem like an ideal solution. Injecting a dummy connection object before destroying the mysql object might be better but I thought I'd see if anyone else had a better idea before writing that.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dean Reilly’s picture

Status: Active » Needs review
FileSize
693 bytes

Patch attached.

alexpott’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

It'd be great to get some tests here...

Garrett Albright’s picture

Issue summary: View changes

Steps to replicate the error in normal Drupal site behavior would be great as well.

alexpott’s picture

Status: Needs work » Closed (duplicate)

The issue came up with batching configuration imports. We shouldn't be serialising the database connection. The solution to this problem has already been implemented in #2004282: Injected dependencies and serialization hell . I guess when we implement #2004370: Batch the configuration synchronisation process we might have to make the ConfigImporter extend DependencySerialization.