Stop creating a unique constraint for add_index unique: true in Migration[8.2]+

[yahonda]

Phase 2 of the implicit-UNIQUE-CONSTRAINT deprecation (#2702), built on the Migration::CompatibilityBehavior extension point. Supersedes #2814 and #2710.

Behavior

Migration[8.2] and later treat add_index :col, unique: true as "create only the unique index" — matching Rails-core PostgreSQL/MySQL/SQLite. Migration[8.1] and earlier keep the pre-8.2 behavior of also creating a same-named UNIQUE CONSTRAINT, so existing migrations replay unchanged. Callers that need a constraint on Migration[8.2]+ should call add_unique_constraint :t, :col, name: :n directly.

Implementation

• OracleEnhanced::CompatibilityBehavior::V8_1 sets an internal _implicit_unique_constraint: true flag in create_table, add_index, create_join_table, and — inside the reference's index options — add_reference/add_belongs_to. The adapter consumes and deletes the flag before further processing (including remove_index/drop_table, which receive it through CommandRecorder inversions on migrate :down), so it never reaches DDL emission (an options flag rather than a thread-local: migrations are single-threaded).
• New implicit_unique_constraint_active? adapter helper ORs the global add_index_unique_creates_constraint flag with the per-call _implicit_unique_constraint flag.
• OracleEnhancedAdapter.add_index_unique_creates_constraint default flips from true to false. The flag remains as an explicit opt-in for projects that want the pre-8.2 behavior project-wide.
• Specs that exercise the pre-8.2 path use with_implicit_unique_constraint_enabled in spec_helper.rb, which toggles the global flag around a block.
• migration_compatibility_spec.rb gains a second top-level describe block covering add_index, inline t.index in create_table/change_table/create_join_table, add_reference/t.references with unique indexes, and a migrate :down cycle — each under both Migration[8.2] (no implicit constraint, no warning) and Migration[8.1] (implicit constraint + deprecation warning) — plus a Migration[7.0] case and an explicit-flag override case.

Tests

migration_compatibility_spec.rb (behavior resolution + unique-constraint version matrix), schema_dumper_spec.rb, schema_statements_spec.rb, structure_dump_spec.rb, and dbms_metadata_structure_dump_spec.rb; CI runs the suite against Oracle.

Depends on

• Add CompatibilityBehavior plumbing for per-adapter migration compatibility #2823: Add CompatibilityBehavior plumbing for per-adapter migration compatibility — merge that first; its commit is the first of the two commits in this PR's diff.
• Rails framework PR introducing compatibility_behavior_for and Migration::CompatibilityBehavior (currently yahonda/rails branch per-adapter-migration-compatibility-v7). Add CompatibilityBehavior plumbing for per-adapter migration compatibility #2823's commit points the Gemfile at that branch.

Independent of #2816: after #2823, either PR can merge first; whichever merges second needs a trivial rebase (both touch V8_1#create_table and append to migration_compatibility_spec.rb).

Review follow-up: change_table inline index coverage

A fresh review found that change_table { |t| t.index :col, unique: true } dispatches through Table#index, which called the connection's add_index directly and bypassed CompatibilityBehavior::V8_1#add_index. Under Migration[8.1] this dropped the implicit UNIQUE constraint for the change_table path only, so older migrations using inline unique indexes inside change_table would not replay unchanged.

The fix keeps this adapter-specific routing in the adapter: V8_1 carries a nested TableDefinition module that the yahonda/rails per-adapter-migration-compatibility-v7 branch's compatible_table_definition prepends generically onto the table object yielded by create_table/change_table. The framework stays free of any index-specific or adapter-only routing (it carries no per-adapter accessor either). The module injects the per-call flag only on the immediate-execution change_table receiver — the create_table path is covered by the table-level flag, and Rails validates per-index option keys during table creation. Any other t.<method> can be customized the same way if future version compatibility requires it.

This PR adds the matching coverage in migration_compatibility_spec.rb: change_table { t.index unique: true } under Migration[8.2] (index only, no warning) and Migration[8.1] (implicit constraint + deprecation warning), plus a Migration[7.0] add_index case confirming pre-8.1 versions resolve to the V8_1 behavior and keep the implicit constraint. The Migration[8.1] change_table case exercises the framework's compatible_table_definition prepending the V8_1::TableDefinition module.

Review follow-up (2026-07-02, second pass)

A second review pass added the following, since folded into the single commit:

• add_reference index: { unique: true } (and t.references inside change_table) was not version-aware. The reference path builds a fresh OracleEnhanced::Table that never went through compatible_table_definition, so under Migration[8.1] the implicit constraint was silently dropped — no deprecation warning either — and a later add_foreign_key targeting that column would fail with ORA-02270. V8_1#add_reference (+ add_belongs_to) now injects the flag into the reference's index options, and the V8_1::TableDefinition module covers t.references/t.belongs_to inside change_table like t.index. create_join_table (which calls the connection's create_table internally, bypassing V8_1#create_table) is covered as well. Specs cover these paths under 8.2 and 8.1.
• The deprecation message was rewritten for Phase 2. After the flip the global flag already defaults to false, so the old "set the flag to false" advice silenced nothing in the main path that still warns (the V8_1 per-call flag). The message now states the trigger — the migration's declared version, or the global flag — and leads with the version-based remediation, keeping the add_unique_constraint guidance.
• migrate :down flag hygiene + a vacuous spec. CommandRecorder straight reversions replayed remove_index/drop_table with _implicit_unique_constraint still set; both methods now delete it at entry, with a spec pinning the up/down cycle. The dbms_metadata structure-dump round-trip spec had also become vacuous after the flip (no backing constraint was created any more); it now uses with_implicit_unique_constraint_enabled like its sibling.

[yahonda]

Builds on #2823 (its commit is included here), which in turn depends on rails/rails#58162 — the Active Record change that adds the compatibility_behavior_for extension point. CI here runs against that rails branch until #58162 merges.