[10.x] Allow adding column constraints in migrations (incomplete) #46883
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
month
orday_of_week
column are valid values in a standard range instead of any integer.discount_amount
isn't larger than thetotal_amount
for an order or invoiceAlthough 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 theBlueprint
andColumnDefinition
classes to allow for this kind of syntax in migrations: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:
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.