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.
Comment | File | Size | Author |
---|---|---|---|
#1 | serialise-mysql-connection-2004346-1.patch | 693 bytes | Dean Reilly |
Comments
Comment #1
Dean Reilly CreditAttribution: Dean Reilly commentedPatch attached.
Comment #2
alexpottIt'd be great to get some tests here...
Comment #3
Garrett Albright CreditAttribution: Garrett Albright commentedSteps to replicate the error in normal Drupal site behavior would be great as well.
Comment #4
alexpottThe 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.