Problem/Motivation

When configuration is checked against schema, schema checker validates that values are correct according to schema, it also checks that schema exists for that value, but ..
There is problem if schema defines some value, but value is not provided in configuration -> schema check doesn't complain about that!

Is that by design, that configuration values can be simply omitted?

I think that schema check should complain if configuration parts are missing.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mtodor created an issue. See original summary.

mtodor’s picture

Status: Active » Needs review
FileSize
1.17 KB
62.52 KB

I have made checking for mapped configuration schema types (see attached patch), I'm not sure does it cover all cases when configuration is missing (probably, not base keys). But still, it gives interesting results.

For example, instead of returning errors, but just logging problematic schema keys into file:

// Instead of
// $errors[$error_key . '.' . $schema_key] = "key is defined in schema, but it is not provided in configuration";
// use
file_put_contents('test_schema.txt', $error_key . '.' . $schema_key . PHP_EOL, FILE_APPEND);

And then run tests only forDrupal\Tests\views_ui\Kernel\TagTest there will be in total around 900+ missing configuration keys/values (btw. "dependencies" are ignored, because it adds a lot more). You can see output in attached file: test__views_ui__TagTest.txt

So it's "by design", bug or I'm missing something?

P.S. Switching to "Needs review", just to get tests triggered.

Status: Needs review » Needs work

The last submitted patch, 2: 2872958_2.patch, failed testing.

alexpott’s picture

This is by design. Configuration schema was added to the configuration system and was always optional.

It might be worth to make it stricter but this would have to be optional.

mtodor’s picture

Status: Needs work » Closed (works as designed)

@alexpott thank you for clarifying it. In my opinion, schema should be more strict to config, then we would have less broken configurations, update hooks would be forced to update configuration properly and not just partially, etc.

Maybe as first step we could think about introducing "required" option, same as it's defined for kwalify:
http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#schema-rules
At least developers will have option to use it, then quality of configuration handling could be improved over time.

Anyway closing this issue and creating followup, maybe we can think about that: #2874793: Support for required configuration in schema definition.