Problem/Motivation

It is currently not possible to import a complete database dump created with the db-tools.php script if the dump in question contains the schema definition for the cache_container table. This is because the cache_container table is automatically created during the normal bootstrap process, and therefore already exists by the time the import command tries to actually import the dump. Therefore, a SchemaObjectExistsException is thrown and db-tools.php dies, assuming that Drupal is already installed.

Steps to reproduce:

  1. Get you a Drupal, and install it; any profile or database type will do the trick.
  2. Run php core/scripts/db-tools.php dump-database-d8-mysql > dump.php
  3. Empty the database by whatever means you prefer. drush sql:drop works well.
  4. Try to import the dump: php core/scripts/db-tools.php import dump.php

You'll get this error: "An existing Drupal installation exists at this location. Try removing all tables or changing the database prefix in your settings.php file."

Proposed resolution

There are a few ways to solve this, but the least invasive solution is for DbImportCommand to destroy the container cache bin just before the import begins. That way, there is no chance of a schema conflict, and the cache bin will either be recreated during the import, or automatically on the next request.

Remaining tasks

Write a patch with tests, review and bikeshed it a bit, then commit it.

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

Issue summary: View changes
phenaproxima’s picture

Issue summary: View changes
phenaproxima’s picture

Status: Active » Needs review
StatusFileSize
new1.13 KB

Enjoy you this patch I made.

phenaproxima’s picture

Issue summary: View changes
Issue tags: -Needs manual testing +Needs tests

Ah, it turns out there is automated test coverage of db-tools.php. Let's add some of that goodness.

Status: Needs review » Needs work

The last submitted patch, 4: 3006038-4.patch, failed testing. View results

phenaproxima’s picture

Status: Needs work » Needs review
StatusFileSize
new2.17 KB
new901 bytes

This should correct the kernel test failure. However, this will still need a full end-to-end functional test, like QuickStartTest.

dawehner’s picture

+++ b/core/lib/Drupal/Core/Command/DbImportCommand.php
@@ -55,6 +55,15 @@ protected function execute(InputInterface $input, OutputInterface $output) {
 
+    // If the database script contains schema for the cache_container table,
+    // the import will fail because that cache table is created as part of the
+    // normal bootstrapping process, which means that it will exist by the time
+    // this command is run, which will raise a SchemaObjectExistsException. By
+    // destroying the cache bin now, we guarantee that either the database
+    // script will recreate it, or it will be automatically recreated during the
+    // bootstrapping of the next request.
+    \Drupal::cache('container')->removeBin();

Reading up on the different implementations of removebin this feels not the right thing to do. Why do we not use deleteAll() instead?

phenaproxima’s picture

Because the problem is not that there is data in cache_container; the problem is that the table exists at all. removeBin() is the only way for calling code to remove the table.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

quietone’s picture

Status: Needs review » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative

@phenaproxima, thanks for patch!

Using the steps in the IS I was not able to reproduce this on 8.9.x or 9.2.x.

Therefore, closing as cannot reproduce. If you are experiencing this problem reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!