fix: handle wildcard '*' in --context parameter for UpdateDatabase an…

[BrunoSync]

Fix wildcard '*' support in --context parameter

Fixes #38254

What was done

• Added wildcard '*' handling in UpdateDatabase — when --context * is passed, the operation now calls CreateAllContexts() and iterates over all found contexts
• MigrationsBundle is covered by this fix since it internally calls UpdateDatabase
• Added test UpdateDatabase_with_wildcard_context_runs_for_all_contexts to verify the fix

Pending

AddMigration also needs wildcard support, but since it returns MigrationFiles, iterating over multiple contexts raises a design question about the return value. Looking for guidance on how to handle this before implementing.

[Copilot]

Pull request overview

This PR adds wildcard --context * handling to migration database updates so EF Core tooling can attempt to update all discovered DbContext types.

Changes:

• Adds a wildcard branch in MigrationsOperations.UpdateDatabase.
• Adds a test intended to cover wildcard update behavior across multiple contexts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/EFCore.Design/Design/Internal/MigrationsOperations.cs	Adds CreateAllContexts() iteration for contextType == "*".
test/EFCore.Design.Tests/Design/Internal/MigrationsOperationsTest.cs	Adds wildcard update test coverage.

[BrunoSync]

Implementation Notes for Review

Hi @dotnet/efcore-team,

I've addressed the wildcard * support for the --context parameter as described in #38254. Here are the key decisions:

Changes Made

1. Wildcard Implementation: When contextType == "*", the method now discovers all DbContext types via CreateAllContexts() and applies migrations to each one sequentially.

2. Error Handling: Consistent with the non-wildcard path—throws OperationException with NoContext when no contexts are discovered. This prevents silent failures.

3. MigrationsBundle Coverage: Automatically works since it internally calls UpdateDatabase.

4. Code Style: Added braces around SetConnectionString call to match existing patterns in the file.

Design Decision: Why AddMigration is Excluded

AddMigration returns MigrationFiles (single result). Supporting wildcard would require either breaking the API contract or changing the method signature. I believe this deserves separate architectural discussion and should be a follow-up issue.

Testing Approach

I noticed UpdateDatabase has no existing unit tests in the codebase. The method's infrastructure dependencies (real DbContext instances, IMigrator services) make traditional unit testing challenging. The implementation is validated through:

• Manual CLI testing with multiple contexts
• Behavioral consistency with the non-wildcard code path
• Proper edge case handling

Please let me know if you'd like me to approach testing differently or if there's additional context needed.

Thanks for reviewing!

[AndriySvyryd]

AddMigration also needs wildcard support, but since it returns MigrationFiles, iterating over multiple contexts raises a design question about the return value. Looking for guidance on how to handle this before implementing.

That would be a big change, so it should be done separately - #38278
For now, just throw an exception saying it's not supported. Same for GetMigrations, ScriptMigration, RemoveMigration, GetContextInfo and DropDatabase