Support for CHECK constraints

[Muppets]

Thought I would pick this up as it sounded easy enough. Turns out it was probably more of a fundamental change than I was expecting and I feel I'm slightly out of my depth.

I feel like I've missed a ton of unit tests along the way. Feel free to rip it apart or send me in a different direction if it's not implemented correctly. Designed by example on this one.

Summary of the changes

• Implemented CHECK constraint in a similar fashion to unique constraints.
• I moved the name property from being an annotation property to be required when specifying the constraint
• Added HasCheckConstraint to EntityTypeBuilder (unsure on this name, open to better ones)
• Added Add and Drop operations for check constraint. Decided to not implement a rename operation so it just calls Drop and Add for changes in name or logical expression.
• Not added any scaffolding code for finding existing check constraints in the database, wasn't sure if this was needed/wanted, or how to implement that.
• Not added anything out of the box for auto adding check constraints to Enum type columns. Felt like this could be added as another issue with this support in the bag.

Fixes #14425

[bricelam]

Direction is good, but we should settle on the IModel changes before moving forward.

[bricelam]

Would be cool to take a C# expression and use the query pipeline to generate the SQL. We have similar ideas for ToView().

If we did that, these could also be implemented for the in-memory provider (it would just evaluate the expression)

[bricelam]

If this becomes specific to relational (and we don't take C# expressions), we should call this sql instead of expression.

[roji]

I think this was also discussed at some point for expressing global filters, maybe we should track all places which could benefit from this in a new issue.

In any case, it will always be desirable to provide a raw SQL overload (for expressions which for any reason can't be expressed otherwise)

[Muppets]

I'm liking the idea for the C# expression overload. Any pointers on where I could find examples of using the query pipeline to generate SQL like that already?

[roji]

I think finalizing the raw SQL version is a good first goal - an expression overload isn't going to be a simple task... In addition the query pipeline is being redone at the moment, so it may not be the best timing. Finally, expression make sense in other places, not just this one, so it may be better to tackle them together later. So I'd recommend concentrating only on SQL for now - we know we want it anyway - but as @bricelam wrote make sure everything is compatible with adding expressions later.

[bricelam]

Another crazy idea: We could create these by convention based on validation attributes:

Attribute	Expression
[Compare("Y")]	X == Y
[MinLength(8)]	X.Length >= 8
[Range(0, 10)]	X >= 0 && X <= 10
[RegularExpression("[0-9A-F]+")	Regexp.IsMatch(X, "[0-9A-F]+")
[DataType(...)]	(predefined regular expressions)

[phatcher]

Couple of things to consider if you want to support OOB

1. Convention based naming e.g. "CH_{TableName}_{ColumnName}", 99% of the time there is at most one check for a column
2. Expressions based on comparing two columns e.g Start < FInish, i.e. can you generate the code from a C# lamda.

[Muppets]

@bricelam Right, I think I've completed the review changes.

One bit I'm not happy with is that CheckConstraints collection hangs off RelationalModelAnnotations which feels wrong as it relates to entity types so maybe it should live on RelationalEntityTypeBuilderAnnotations?

[AndriySvyryd]

It's fine for CheckConstraints collection to hang off RelationalModelAnnotations for now. The reason it feels wrong is because it should be associated with a table, but to properly represent that we need a store model.

[AndriySvyryd]

@Muppets Generally it's looking good, so it's time to rebase and squash so we can have a final review.

[Muppets]

@AndriySvyryd I know this might not be the right place to ask this but after a few touch and go moments rebasing and squash some other branches, do you guys have any tips on how you generally rebase and squash changes on a branch to master?

[AndriySvyryd]

@Muppets There's nothing specific to our repo that I can think of. It helps to rebase frequently, you can do it retroactively by rebasing to a specific older commit.

[AndriySvyryd]

@Muppets Thanks for your contribution!

[roji]

Note follow-up in #17085

[Muppets]

Thanks @roji. Definitely felt light on the tests for this.