Problem/Motivation

hook_schema() creates a strong dependency between module installation and services provided by modules. This means for example that we have to use KernetTestBase::installSchema() in kernel tests.

We have an existing pattern in core which avoids this, the ::ensureTableExists() pattern. With this, services are responsible for creating their database schema on demand. Some examples: https://api.drupal.org/api/drupal/9.3.x/search/ensureTableExists

Steps to reproduce

Proposed resolution

Apply this pattern to more core services. Eventually deprecate hook_schema() once it's no longer used in core.

At the same time, look at adding a more formal API:
#2371709: [PP-x] Move the on-demand-table creation into the database API

Note that #2665216: Deprecate Drupal\Core\Database\Connection::nextId() and the {sequences} table and schema removes a hook_schema() implementation by replacing it with key value.

Remaining tasks

Open issues to replace the following hook_schema() implementations, focusing on modules which will not be deprecated for removal in Drupal 11.

system_schema() - #3428565: Implement lazy database creation for sessions
layout_builder_schema()
search_schema()
user_schema()
node_schema()
locale_schema()
ban_schema() - #3379255: [PP-1] Replace ban_schema() implementation with ::ensureTableExists()
help_topics_schema()
forum_schema()
book_schema()
history_schema()
tracker_schema()
dblog_schema()
shortcut_schema()
comment_schema()
file_schema()
workspaces_schema()

Once all core hook_schema() usages have been converted, consider opening a follow-up to deprecate hook_schema() itself.

User interface changes

API changes

Data model changes

Release notes snippet

Comments

catch created an issue. See original summary.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

Only one issue left in summary, probably could be closed

catch’s picture

I think we need more child issues, there is still the following hook_schema() implementations in core:

layout_build_schema()
search_schema()
user_schema()
node_schema()
locale_schema()
ban_schema()
help_topics_schema()
forum_schema()
book_schema()
history_schema()
tracker_schema()
dblog_schema()
shortcut_schema()
comment_schema()
file_schema()
workspaces_schema()

Some of these modules are slated for removal so it might be more efficient for us to deprecate the modules rather than refactoring, but several aren't.

andypost’s picture

help topics will be moved to help but that's for purpose of search

comment statistics IIRC there's #2318875: Redo CommentStatisticsInterface
the same is for history and taxonomy

So yep, makes sense to keep

catch’s picture

Issue summary: View changes

Added the list to the issue summary.

nlisgo’s picture

Issue summary: View changes
nlisgo’s picture

I've started on #3379255: [PP-1] Replace ban_schema() implementation with ::ensureTableExists().

It would be great to get some help on this one and then we have a template on how to approach the others. I need a little support to understand how to hook up the process to delete the table once the module is uninstalled.

nlisgo’s picture

I reached out for some support on slack regarding an approach to tear down tables when modules are uninstalled. This process needs to be clearer before we progress. The current implementations of this approach have all been for core services so we don't need to support tear down. This is obviously a necessity for any implementations within a module.

Hat tip: @berdir (for your support on slack)

nlisgo’s picture

Update from @catch on slack:

You can drop the tables on uninstall. In ModuleInstaller, it calls removeBin when a module providing a cache bin is uninstalled, and the database backend drops the table in ::removeBin()

catch’s picture

catch’s picture

Issue summary: View changes
nicxvan’s picture

Issue summary: View changes
nicxvan’s picture

The ban module change is ready.

I have to say wrapping every call in an ensure table exists feels really cumbersome do we think #2371709: [PP-x] Move the on-demand-table creation into the database API makes this transparent?

Is probably better to resolve that first then.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

penyaskito’s picture

Done this for canvas (#3585192: Don't rely on hook_schema for canvas notifications table). Agree with @nicxvan that #2371709 is necessary, or at least some helpers should be provided. The patterns are quite common, but at the moment this can't be done without some boilerplate.