Voting starts in March for the Drupal Association Board election.
Suggested commit message:
Issue #2293063 by reyero, Gábor Hojtsy, chx, Wim Leers: Config schema mapping parsing is inconsistently forgiving, does not conform to the interface
This came up in, causes problems debugging schemas in and is just not consistent.
1. If you define a type as
type: boo and the boo type does not exist, it will fall back on an undefined type. If you define the type as
type: boo.[type] (where type is foo) and there is no specific type defined for
boo.foo and there is no
boo.*, the type will fall back on undefined. This is true for each individual element, sequence elements, etc. So the type definitions are very resilient when it comes to errors. Except if you forget/miss to define a key on a mapping, all hell breaks loose and you cannot iterate into that element in the mapping or request elements under it with the schema. This is obscured for the schema validation and value casting use cases because it swallows up the exceptions thrown. But this hides several real problems. Compared with how resilient everything else is, this is totally not expected.
2. We made up our own SchemaIncompleteException and even use it for cases when you try to access a key on a mapping that is not there (so why on earth would you have a schema for it?). The interface documents that an InvalidArgumentException should be thrown in this case, so we should do that instead of deviating from what the interface says is happening.
3. Once we do this, several things start to fail because now actual failures are surfacing where an item was not defined as an array but is attempted to be used as such. We need to fix these fails because they are actual schema mismatches. With those concrete issues fixed, the new system is more resilient to undefined items and more strict for how defined elements enforce their type and fail on issues instead of hiding these real errors.
1. Use the same fallback mechanism for types on undefined mapping elements that is on for sequence and other types.
2. Instead of making up our own exception (and then misusing it) only for undefined mapping keys but not for anything else, use the exception expected according to the interface we implement.
3. Fix the resulting fails.
4. Add testing foe the fixed mapping behaviour.
Tests. Review. Commit.
User interface changes
Instead of throwing exceptions on keys if their schema is not defined, Mappings will be more resilient in this case. For nonexistent keys, it will throw the expected InvalidArgumentException.
|#30||interdiff-and-test-only-patch-in-one.patch||1.71 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,677 pass(es), 1 fail(s), and 1 exception(s). View
|#30||2293063-mapping-resilient-and-interface-fix-30.patch||18.17 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,839 pass(es). View
|#27||2293063-mapping-resilient-and-interface-fix-25.patch||16.45 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,722 pass(es). View
|#25||interdiff.txt||621 bytes||Gábor Hojtsy|
|#24||interdiff.txt||1.75 KB||Gábor Hojtsy|