Drop sequences table in Drupal 12

Isn't this supposed to be removed in Drupal 12? At least that's what the deprecation messages in the original issue said.

sorry, mixed with method deprecation

Let's do this in #3573896: Remove deprecations from System module

I take that back, there are complications with install_begin_request in install.core.inc that need untangling and it might be better to address that here. Specifically this bit:

if ($install_state['settings_verified']) {
  try {
    $system_schema = system_schema();
    $table = array_key_last($system_schema);
    $install_state['base_system_verified'] = Database::getConnection()->schema()->tableExists($table);
  }
  catch (DatabaseExceptionWrapper) {
    // The last defined table of the base system_schema() does not exist yet.
    // $install_state['base_system_verified'] defaults to FALSE, so the code
    // following below will use the minimal installer service container.
    // As soon as the base system is verified here, the installer operates in
    // a full and regular Drupal environment, without any kind of exceptions.
  }
}

Theoretically (very theoretically), this might allow us to remove the special casing of system module in the early installer altogether. We should see what happens if that hunk is removed.

I don't think we can just remove this hunk. There is also install_verify_database_ready which looks at system_schema. If the last table in that function (i.e. sequences) exists then this prevents installing Drupal over and existing installation. With the sequences table gone we lose that check. Perhaps we can check for a different table? It looks like key_value is the first to be created, followed by config. But is it possible that someone is swapping out those services so they are not in the database after all? Not sure if that's possible at install time.

btw Drush already doing a check for key_value table to detect install https://github.com/drush-ops/drush/blob/14.x/src/Boot/DrupalBoot8.php#L162

I bet even if some module override this (for example mongodb) then Drush will fail somehow OTOH before install core probably should create some tables, so I bet we can remove this check at all

PS: Code search showing no usage in contrib so we can remove it

Create WIP MR to see if it will work as no usage of the system_schema() found, not sure about check and comment setUpCurrentUser() in core/modules/user/tests/src/Traits/UserCreationTrait.php

Also curious to explore #11

After removal system module can be installed https://git.drupalcode.org/project/drupal/-/merge_requests/14809/diffs?c...

removed testing commit for #11 as it need more changes breaking resumed installs (when browser closed while install) so the two-phase bootstrap can be removed if drupal_install_system() and services become idempotent to re-run installer. Needs follow-up for that like #2934063: Remove the workaround in \Drupal\Core\Installer\ExtensionListTrait::setPathname() which fails one test now

mongodb is implemented as a database driver so most of the time it's not actually swapping out database tables but creating collections with the same name so things work transparently - I think, this is based on what @daffie has told me not manual review.

In the early installer, even if you have an alternative database driver that is swapping something out, it's not an installed module yet, so the swapping wouldn't be possible at that point anyway.

tl;dr I think it's OK to rely on key_value here.

Filed #3574200: Get rid of 2-phase kernel boot in installer

I assume this needs update path tests, so I'm tagging for them and setting the status to Needs Work.

Otherwise, I didn't find anything to comment on. The sequences table isn't installed anymore. The update function removes it from existing installs. The installer redirects properly if the key_value table is missing. It was a little hard to test the partial install state functionality of core.install.inc, but I think I got it. It worked properly.

For update path tests, because this is a system update it will be run in every update path test anyway, so I think we could find a generic one and add an assertion there that the table no longer exists after the update? Can't think of anything else though.

Added to core/modules/system/tests/src/Functional/Update/RouteAliasUpdateTest.php as it's only one that already testing database upgrade

That looks OK to me. Thank you.

We can't add this to the update path test for route aliases, because that update path will be removed entirely in 12.x when we remove all updates added prior to 11.3.0

yep, system_update_11201 will gone in 12.x but update is 12000 so probably better to make it 1x001 so the whole could be removed for 12.x

Only TODO can solve it even for new test

New test coverage looks good.

Committed/pushed to main, thanks!

-/**
- * Implements hook_schema().
- */
-function system_schema(): array {

This took years, and good to finally get there!