fix: remove old constraint

[betodealmeida]

SUMMARY

The dataset model has a comment that says:

superset/superset/connectors/sqla/models.py

Lines 1135 to 1144 in 9487d6c

	# Note this uniqueness constraint is not part of the physical schema, i.e., it does
	# not exist in the migrations, but is required by `import_from_dict` to ensure the
	# correct filters are applied in order to identify uniqueness.
	#
	# The reason it does not physically exist is MySQL, PostgreSQL, etc. have a
	# different interpretation of uniqueness when it comes to NULL which is problematic
	# given the schema is optional.
	__table_args__ = (
	UniqueConstraint("database_id", "catalog", "schema", "table_name"),
	)

But turns out there is an old migration from 2016 that adds the uniqueness constraint to the schema:

superset/superset/migrations/versions/2016-04-15_08-31_b4456560d4f3_change_table_unique_constraint.py

Lines 36 to 38 in 9487d6c

	op.create_unique_constraint(
	"_customer_location_uc", "tables", ["database_id", "schema", "table_name"]
	)

With the introduction of catalogs in SIP-95 this constraint needs to either be updated to include catalog, or removed to align with the SqlaTable model. In this PR I went with the latter.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[eschutho]

Should we raise again if it fails so that it rolls back? What are the implications here if there is an error and we can't roll back the transaction because we are not raising again? Can you use generic_find_uq_constraint_name to see if the constraint exists?

[betodealmeida]

Yeah, good point, I think we can use generic_find_constraint_name. I'm a bit concerned that the method might not work for all databases, but it should work with the most common at least.

[mistercrunch]

Hey, thinking about applying some of the ideas in #29546, which would point towards either accumulating this PR and holding it until next release, or merging this in to a no-op place that we would bring into an actual migration later.

Curious as to whether you all think it's better to hold the PR, or to merge into a temporary place.

[mistercrunch]

Easiest option here seems like it'd be to add a hold:next-major:migration label (or similar) and defer