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

[Copilot]

Pull request overview

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

Files not reviewed (1)

• src/EFCore.Design/Properties/DesignStrings.Designer.cs: Language not supported

Comments suppressed due to low confidence (2)

src/EFCore.Design/Design/Internal/MigrationsOperations.cs:244

• CreateAllContexts() is an iterator that creates a DbContext as it is enumerated, so calling Any() here constructs the first context and then abandons it undisposed before the foreach creates a second instance. Use a single enumeration pattern (for example, the contextOptimized flag used by DbContextOperations.Optimize) to avoid leaking the first context and duplicating its side effects.

            var contexts = _contextOperations.CreateAllContexts();

            if (!contexts.Any())
            {
                throw new OperationException(DesignStrings.NoContext(_assembly.GetName().Name));
            }

            foreach (var item in contexts)

src/EFCore.Design/Properties/DesignStrings.resx:517

• The <value> element is indented differently from the rest of this .resx file (nearby resource values use four spaces under <data>). Please align it with the existing XML formatting.

  <data name="WildcardNotSupported" xml:space="preserve">
  <value>The wildcard '*' is not supported for this command.</value>
  </data>

[BrunoSync]

Thanks for the detailed review! Addressing all three points:

GetContextInfo wildcard: Good catch. Since MigrationsBundleCommand calls GetContextInfo internally to get the context type for Program.cs generation, throwing there would break the bundle scenario. My proposal is to remove the wildcard check from GetContextInfo and move it directly into MigrationsBundleCommand.Execute instead, keeping each command responsible for its own validation. Does that sound right?

Tests: I tried adding tests for the wildcard path in UpdateDatabase but ran into difficulties since it requires real IMigration implementations and a database connection. How does the project usually handle testing this kind of integration flow? Happy to follow whatever approach is standard here.

[AndriySvyryd]

My proposal is to remove the wildcard check from GetContextInfo and move it directly into MigrationsBundleCommand.Execute instead, keeping each command responsible for its own validation. Does that sound right?

Add it to MigrationsBundleCommand.Execute but also keep it in GetContextInfo

How does the project usually handle testing this kind of integration flow?

The tools are currently just tested manually