mirror of
https://github.com/dotnet/skills.git
synced 2026-09-20 09:49:54 +08:00
Dan Moseley
042a9d2b2c
* Reorganize plugins per agreed structure (#271) Split the dotnet plugin into domain-specific plugins per discussion in #271: - dotnet: narrowed to common everyday C#/.NET coding tasks - dotnet-diag: perf investigations, debugging, incident analysis - dotnet-data: data access and Entity Framework - dotnet-aspnet, dotnet-wpf, dotnet-winforms, dotnet-maui: scaffolded empty to convey intent for future framework-specific skills Moved skills, tests, and CODEOWNERS entries accordingly. No file content was changed; all skill/test moves are pure renames. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Improve dotnet-diag and dotnet-winforms descriptions - dotnet-diag: add '.NET' qualifier to clarify scope - dotnet-winforms: use official 'Windows Forms (WinForms)' name Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add .NET qualifier to dotnet-data description Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Remove empty plugins; list them in CONTRIBUTING.md as future options Remove the four empty placeholder plugins (dotnet-aspnet, dotnet-wpf, dotnet-winforms, dotnet-maui) that had only plugin.json and no skills. Add a 'Plugin organization' section to CONTRIBUTING.md that describes the domain-specific plugin groupings introduced in this PR and lists the four removed plugin names as reserved candidates for future contributions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Create dotnet-upgrade plugin with migration/upgrade skills Move migrate-nullable-references, thread-abort-migration, and dotnet-aot-compat from dotnet to the new dotnet-upgrade plugin. Update CODEOWNERS paths (same owners), CONTRIBUTING.md plugin table, and fix the thread-abort-migration SKILL.md link in CONTRIBUTING.md. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
42 lines
1.8 KiB
YAML
42 lines
1.8 KiB
YAML
scenarios:
|
|
- name: "Optimize bulk operations with EF Core 7+ ExecuteUpdate and ExecuteDelete"
|
|
prompt: |
|
|
I have an EF Core 8 app. These two operations are extremely slow because they load all entities into memory:
|
|
|
|
```csharp
|
|
// Operation 1: Deactivate all products not sold in 6 months
|
|
var staleProducts = await _db.Products
|
|
.Where(p => p.LastSoldDate < DateTime.UtcNow.AddMonths(-6))
|
|
.ToListAsync();
|
|
foreach (var p in staleProducts)
|
|
{
|
|
p.IsActive = false;
|
|
}
|
|
await _db.SaveChangesAsync();
|
|
|
|
// Operation 2: Delete all audit logs older than 1 year
|
|
var oldLogs = await _db.AuditLogs
|
|
.Where(l => l.CreatedAt < DateTime.UtcNow.AddYears(-1))
|
|
.ToListAsync();
|
|
_db.AuditLogs.RemoveRange(oldLogs);
|
|
await _db.SaveChangesAsync();
|
|
```
|
|
|
|
There are 500K products and 2M audit logs. How do I make these efficient?
|
|
assertions:
|
|
- type: "output_matches"
|
|
pattern: "(ExecuteUpdateAsync|ExecuteUpdate)"
|
|
- type: "output_matches"
|
|
pattern: "(ExecuteDeleteAsync|ExecuteDelete)"
|
|
- type: "output_matches"
|
|
pattern: "(SetProperty|set.*property)"
|
|
rubric:
|
|
- "Recommended ExecuteUpdateAsync for the bulk update instead of loading entities (EF Core 7+ feature)"
|
|
- "Used the correct SetProperty lambda syntax: SetProperty(p => p.IsActive, false)"
|
|
- "Recommended ExecuteDeleteAsync for the bulk delete instead of loading and RemoveRange"
|
|
- "Explained that ExecuteUpdate/ExecuteDelete bypass change tracking and execute as single SQL statements"
|
|
- "Warned about limitations: no cascade deletes triggered, no change tracker notification, bypasses interceptors/events"
|
|
- "Showed the correct LINQ-to-SQL translation (WHERE + UPDATE/DELETE without SELECT)"
|
|
expect_tools: ["bash"]
|
|
timeout: 120
|