[10.x] Allow adding column constraints in migrations (incomplete)

[jameshulse]

This is a request for feedback on whether this is an idea that I should keep building out. The PR is a proof of concept currently, but is functional.

Overview

The basic premise is to have an easy way to add CHECK constraints to database tables. These constraints are a useful way to ensure that the data that is persisted to your database is always in a good state. They are supported in Postgres, MySQL and MS SQL.

Potential use-cases are:

• Ensuring a month or day_of_week column are valid values in a standard range instead of any integer.
• Validating the format of a string such as a Zip code, Phone number, or tax number with regex
• That a discount_amount isn't larger than the total_amount for an order or invoice

Although these should be tackled at the application level with validation, for strong database integrity it can be useful to add these checks at a database level too. Encouraging developers to use this feature should improve the quality of some code bases.

Proposed change

Introduce ->check(...) functions to the Blueprint and ColumnDefinition classes to allow for this kind of syntax in migrations:

function up() {
    Schema::table('company', function (Blueprint $table) {
        ...
       $table->check('check_day_of_week', 'day_of_week >= 1 and day_of_week <= 7');
    });
}


function down() {
    Schema::table('company', function (Blueprint $table) {
        $table->dropCheck('check_day_of_week');
    });
}

There are a few different syntaxes for adding checks, but we wouldn't necessarily have to attempt to support them all. Although adding a check constraint directly at a column level could be useful:

$table->smallInteger('day_of_week')->check('day_of_week >= 1 and day_of_week <= 7');

Caveats

We don't have an easy way to automatically name the check constraint as we don't have a list of columns that we are applying the constraint to for example. Because of this I have added a mandatory $checkName parameter to the function. This isn't how many of the other migration methods work so may be clunky unless we can come up with another solution.

[morloderex]

@jameshulse this was already tried recently in #46512.

I am not sure why this other pr was rejected tho just pointing it out.

[jameshulse]

@morloderex, good catch! I hadn't seen that PR. I guess I should probably close this then as the previous PR looks like it was more complete than what I have here.

Having a package to handle this with macro's would probably make enough sense that it doesn't need to be added to the core framework.