fix: tenant migrations should honor module attributes

[rgraff]

such as @disable_ddl_transaction and @disable_migration_lock

Fixes #610

I was not able to get a failing test for this bug. Ecto would not error, but would give a warning. I have two tests and one generates a warning and the other does not. Since they both pass (even with warnings), it's not a reliable regression test.

Contributor checklist

Leave anything that you believe does not apply unchecked.

• I accept the AI Policy, or AI was not used in the creation of this PR.
• Bug fixes include regression tests
• Chores
• Documentation changes
• Features include unit/acceptance tests
• Refactoring
• Update dependencies

[rgraff]

While this fix may work--I'm not 100% certain given the difficulty in testing.

And there's another complication. You still can't do do schema migrations that use the concurrently: true option in test suites, since sandboxes are always in a transaction.

Maybe the migration generator needs to do something like this

create index(:posts, [:title], concurrently: Mix.env() != :test)

[zachdaniel]

Yeah, that makes sense 🤔 We probably will need to figure some other kind of thing out here because you could also be running this in an action that is in a transaction. I'm not sure what the right answer is? Maybe some kind of error if you are in a transaction currently, that can be silenced in test?

[rgraff]

Yeah, it will error in a transaction so at least you’ll know it failed. What about changing the generated migration to include some helpers? For example you only need it to be concurrent if there are existing records. So a new tenant doesn’t need to concurrency on for the initial migrations.

…

On Oct 20, 2025 at 6:13 PM -0700, Zach Daniel ***@***.***>, wrote: zachdaniel left a comment (ash-project/ash_postgres#643) Yeah, that makes sense 🤔 We probably will need to figure some other kind of thing out here because you could also be running this in an action that is in a transaction. I'm not sure what the right answer is? Maybe some kind of error if you are in a transaction currently, that can be silenced in test? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[zachdaniel]

That is a good point. Then future migrations are applied "out of band" out of a transaction. Smart 👍