Require precision and scale for decimal columns

[morozov]

Similar to the string columns (#3263), having the DBAL define the precision and scale of decimal columns doesn't make much sense. The values of precision and scale should reflect the properties of the model represented by the schema.

TODO:

• Deprecate default precision and scale for decimal columns #5637.

[greg0ire]

Is this typically going to be caught and improved with additional context elsewhere, or should we add additional context based on information contained in $column?

[greg0ire]

I got mislead by the variable name (which should probably be $columnOptions, I don't think there is actually going to be anything helpful in there. The concern still stands though: are these exceptions going to be handled at a level where the column's fully qualified name is available?

[morozov]

I understand the problem. We have the same problem in other places, e.g.

dbal/src/Platforms/AbstractPlatform.php

Lines 267 to 271 in 08630c6

	protected function getVarcharTypeDeclarationSQLSnippet(?int $length): string
	{
	if ($length === null) {
	throw ColumnLengthRequired::new($this, 'VARCHAR');
	}

And it's even more acute there since the column name is not available in the scope from where the exception is thrown.

I cannot think of a simple solution at this point. I don't want to introduce a dependency on $column['name'] in the code being added just to use it as a parameter for the exception because the exception is unrelated to the name.

A proper solution might be to improve the exception hierarchy:

1. All these three exceptions should have a common type (e.g. InvalidColumnType).
2. The code that calls the functions that may throw such exceptions should have the column name in its scope and should catch these exceptions and throw a more user-friendly exception (e.g. InvalidColumnDefinition).

[greg0ire]

Approving since as you pointed out, this also happens elsewhere. Let's create an issue out of #5631 (comment) ?

[morozov]

The new issue is #5645.