feat: Add table_constraints field to Table model

[dimkonko]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #1754 🦕

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[chalmerlowe]

@dimkonko
I am reviewing this PR. Thank you for the hard work you have put in. I appreciate it. I would like to work with you to get this merged. I have reviewed the PR and will be making a few comments on some of the code shortly.

Please see the note above about the CLA. We will need that taken care of to proceed. #1755 (comment)

[chalmerlowe]

@dimkonko

Thanks for all this hard work. I appreciate the time and effort.
I would like to request several changes that I hope you can help with. If you need assistance or want to talk anything through, please let us know.

[chalmerlowe]

We have several areas of code that coverage.py does not believe are being tested. Those lines of code are:

• 2968
• 2985-2987
• 3019

For line 2968, it does not appear that we have a test that specifically exercises the raise statement by trying to compare an input value that is not a PrimaryKey.

[dimkonko]

Yep, I missed the coverage part 😅 Thank you for pointing that out. I've added missing coverage in commit 29d1238

[chalmerlowe]

My understanding from the Python documentation is that:

TypeError: Is raised when an operation or function is applied to an object of inappropriate type. The associated value is a string giving details about the type mismatch.

This exception may be raised by user code to indicate that an attempted operation on an object is not supported, and is not meant to be. If an object is meant to support a given operation but has not yet provided an implementation, NotImplementedError is the proper exception to raise.

Passing arguments of the wrong type (e.g. passing a list when an int is expected) should result in a TypeError, but passing arguments with the wrong value (e.g. a number outside expected boundaries) should result in a ValueError.

Suggested change

	raise NotImplementedError
	raise TypeError("The value provided is not a BigQuery PrimaryKey.")

[dimkonko]

@chalmerlowe oh, right. Thank you. I missed that. It should be return but not raise.
I think we should not raise anything here to not cause errors and to be consistent with the existing code.

[chalmerlowe]

For this portion of the mod (2985-2987), coverage.py indicates that we are not exercising this code fully.

We do have tests that reference ColumnReferences, but not necessarily in a way that fully exercises each line of this code.

[dimkonko]

Thanks. I've added column_references to the __eq__ in commit da663b2

[chalmerlowe]

This (3019) is also identified by coverage.py as being untested

[chalmerlowe]

Change all NotImplementedErrors as noted in the previous comment to look similar to this:

TypeError("<add a suitable message for the user to figure out the problem.")

[chalmerlowe]

LGTM.
@dimkonko

Thanks for all your hard work pulling this together and thanks for your patience as I worked through the review process. I am grateful for your time and effort.