As a Site Admin I want to have sensible defaults when enabling Search API DB

Would this then happen completely automatically when enabling the module? Or what's the idea?
What I could imagine, when there is neither an index nor a server yet, having a button on the Search API admin overview page for creating a default setup. This could then also have simple configuration, if really necessary (multiple backends are available, or the backend cannot provide a default for some setting).

However, if we do this now it should be light-weight and self-contained enough to be easily ripped out again later if we come up with a more holistic approach to user-friendliness (i.e., #2387893: Overhaul administration UI).

Shipping default configs seems light-weight to me, and easily updateable and changeable, so I don't see much risk.

Automatically creating a server when enabling the Database Search module does make sense, yes.
However, while we initially planned to do it, it's completely impossible to have a default index or search page as configuration, as you don't know which datasources will be available. Not even the Node module is required anymore, so even doing a default node index isn't possible anymore, without code checking whether the module is there.

So, I totally agree with having a default server in the Database module, but anything else would be significantly more complex.

Looks good so far, thanks!
The view is of course still missing (the module should then just also depend on Views, though), also I saw these little issues:

1. +++ b/search_api_db/search_api_db_defaults/config/install/search_api.index.search_api_database_index.yml
   @@ -0,0 +1,189 @@
   +uuid: 62dd515d-ccc7-4304-8000-c13ce6aed478
   

   Default config should never have UUIDs, as far as I now.

2. +++ b/search_api_db/search_api_db_defaults/config/install/search_api.server.server.yml
   @@ -0,0 +1,76 @@
   +  min_chars: 1
   

   Is 1 really the best default here? I think 3 will usually make more sense.
   We do already have that on the Tokenizer, though, so it should probably not matter much (except for numeric tokens, I think?).

3. +++ b/src/IndexListBuilder.php
   @@ -150,7 +150,7 @@ class IndexListBuilder extends ConfigEntityListBuilder {
   +      '#empty' => $entity_groups['lone_indexes'] ? '' : $this->t('There are no servers or indexes defined. For a quick start, we suggest you install the Search API Database Defaults module.'),
   

   Maybe link that to the Modules page?

Hm, yes, I guess that would make sense. Using "1" as the default seemed the most natural selection, since all others are more arbitrary choices, but I guess having a sensible default (at least for English) is still better.

Sorry for the long delay, was very busy unfortunately.
The patch looks already very good, but needed a re-roll. I also found these problems:

1. +++ b/config/schema/search_api.views.schema.yml
   @@ -4,10 +4,13 @@ views.query.search_api_query:
   +      label: If the underlying search index has access checks enabled, this option allows you to disable them for this view
        entity_access:
          type: boolean
   +      label: Execute an access check for all result entities.
        parse_mode:
          type: string
   +      label: Chooses how the search keys will be parsed
   

   See #2473757: Only sentences should end with periods.

2. +++ b/search_api_db/config/schema/search_api_db.backend.schema.yml
   @@ -5,6 +5,9 @@ search_api.backend.plugin.search_api_db:
   +    database_text:
   

   Why include that? I don't think that should ever be in the options, we only use that key for display purposes when editing the server.
   If this results in a value saved in the options, it's definitely a bug (even sounds like one in Core?), and in any case nothing we should replicate in our default configuration.

Regarding your own two remarks in #21: do you want to still implement them here, or should I commit and we'll make a follow-up?
Anyways, patch attached. Set to "Needs work", though, because before #2473717: Add support for per-bundle view modes in the rendered entity processor gets fixed again it will fail anyways.

OK, I just implemented your two suggestions. As I did, I noticed I hadn't reviewed the new test class before. So I also made these changes:

1. +++ b/search_api_db/search_api_db_defaults/src/Tests/IntegrationTest.php
   @@ -80,36 +80,9 @@ class IntegrationTest extends WebTestBase {
   -  /**
   -   * Create article and page bundle with their necessary fields for our default
   -   * configuration.
   -   */
   -  private function createNodeBundles() {
   +  protected function createNodeBundles() {
   

   The first sentence of a doc block should always be on its own line and never exceed 80 characters (including the * preceding it).

   Also, methods should almost never be private.

2. +++ b/search_api_db/search_api_db_defaults/src/Tests/IntegrationTest.php
   @@ -196,9 +171,26 @@ class IntegrationTest extends WebTestBase {
   +   * Tests whether the default search was correctly installed.
   +   */
   +  protected function testDefaultSetupWorking() {
   +    $server = Server::load('default_server');
   +    $this->assertTrue($server, 'Server can be loaded');
   +
   +    $index = Index::load('default_index');
   +    $this->assertTrue($index, 'Index can be loaded');
   +
   +    $this->drupalGet('search/content');
   +    $this->assertResponse(200, 'Anonymous user can access the search page.');
   +    $this->drupalLogin($this->authenticatedUser);
   +    $this->drupalGet('search/content');
   +    $this->assertResponse(200, 'Authenticated user can access the search page.');
   +  }
   

   Since each test method means a complete site install, for performance reason I always try to stick with a single test method (aside from PHPUnit tests).

3. +++ b/search_api_db/search_api_db_defaults/src/Tests/IntegrationTest.php
   @@ -210,8 +202,11 @@ class IntegrationTest extends WebTestBase {
   +   *
   +   * @return \Drupal\field\Entity\FieldConfig
   +   *   The newly created field configuration.
   

   Copying bad code from Core is no excuse to skip the @return tag. ;P

The attached patch is RTBC for me. If the test bot agrees and no-one objects, I'll commit it.

Wow, that was quick! The test bot speed on weekends is insane …
So, since the test bot is happy: committed.
Thanks a lot again, Nick!
(If someone wants to object after all, please re-open!)

With this patch the search_api.index.default_index.yml was committed which is currently not correct and makes the search_api_db_defaults useless.
Here is a screenshot of the database, tables and fields which this config produces on a fresh install:

Every field after the entity:node/title one is missing, which causes errors when indexing as it tries to insert values into a non-existent column.
Here is the issue I created a while back when I initially noticed the issue: #2510564: Indexing is broken
We can probably fix the config in that issue.

If there is already an issue, why did you re-open this one?

Sorry, will do the work in the other issue and close this one.