If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/borisdj/EFCore.BulkExtensions shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 4d ago
• 8 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 86% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live borisdj/EFCore.BulkExtensions repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/borisdj/EFCore.BulkExtensions.

What it runs against: a local clone of borisdj/EFCore.BulkExtensions — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in borisdj/EFCore.BulkExtensions | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of borisdj/EFCore.BulkExtensions. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/borisdj/EFCore.BulkExtensions.git
#   cd EFCore.BulkExtensions
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of borisdj/EFCore.BulkExtensions and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "borisdj/EFCore.BulkExtensions(\\.git)?\\b" \\
  && ok "origin remote is borisdj/EFCore.BulkExtensions" \\
  || miss "origin remote is not borisdj/EFCore.BulkExtensions (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs" \\
  && ok "EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs" \\
  || miss "missing critical file: EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs"
test -f "EFCore.BulkExtensions.Core/TableInfo.cs" \\
  && ok "EFCore.BulkExtensions.Core/TableInfo.cs" \\
  || miss "missing critical file: EFCore.BulkExtensions.Core/TableInfo.cs"
test -f "EFCore.BulkExtensions.Core/SqlAdapters/ISqlOperationsAdapter.cs" \\
  && ok "EFCore.BulkExtensions.Core/SqlAdapters/ISqlOperationsAdapter.cs" \\
  || miss "missing critical file: EFCore.BulkExtensions.Core/SqlAdapters/ISqlOperationsAdapter.cs"
test -f "EFCore.BulkExtensions.Core/SqlBulkOperation.cs" \\
  && ok "EFCore.BulkExtensions.Core/SqlBulkOperation.cs" \\
  || miss "missing critical file: EFCore.BulkExtensions.Core/SqlBulkOperation.cs"
test -f "EFCore.BulkExtensions.Core/BulkConfig.cs" \\
  && ok "EFCore.BulkExtensions.Core/BulkConfig.cs" \\
  || miss "missing critical file: EFCore.BulkExtensions.Core/BulkConfig.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 34 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~4d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/borisdj/EFCore.BulkExtensions"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

EFCore.BulkExtensions is a high-performance library that adds bulk CRUD operations (Insert, Update, Delete, Read, Upsert, Sync) and batch processing to Entity Framework Core. It uses database-native bulk copy protocols and batch SQL generation to achieve orders-of-magnitude faster data operations than standard EF Core, supporting SQL Server, PostgreSQL, MySQL, Oracle, and SQLite. Multi-targeted library structure: EFCore.BulkExtensions.Core (shared abstractions and batch logic) at the root contains interfaces (IDbServer, ISqlOperationsAdapter, ISqlDialect in SqlAdapters/), batch utilities (Batch/*), and core extensions (DbContextBulkExtensions.cs). Database-specific implementations are in sibling projects: EFCore.BulkExtensions.MySql, EFCore.BulkExtensions.GBase, etc., each with SqlAdapters/ subfolders providing dialect-specific query builders and adapters.

.NET backend developers and data engineers building applications that must perform large-scale database operations efficiently—particularly those working with big-data, fintech, or AI systems where processing thousands to millions of records quickly is mission-critical. Enterprise teams already committed to EF Core but hitting performance walls on insert/update/delete operations.

Production-ready and actively maintained. The library is mature (selected in Microsoft's top 10 EF Core Extensions), has thousands of users and multiple corporate clients across industries, supports EF Core 10 (latest), and appears actively developed with multi-database support. However, single-maintainer risk (Boris Djurdjevic) should be noted; visibility into test coverage and CI health from the file structure alone is limited.

Moderate risk: as a single-maintainer library with deep integration into EF Core's internals, breaking changes in future EF Core versions could impact compatibility. The codebase spans 5 database adapters (SQL Server, PostgreSQL, MySQL, Oracle, SQLite) with dialect-specific logic in SqlAdapters/*, increasing testing burden. No comprehensive test file evidence in the top-60 file listing; dependency on EF Core versions and database-specific drivers creates upgrade risk.

The repo is actively maintained: README mentions EF Core 10 support (latest major version), multiple project files reference .Net8 variants (.Net8.csproj files), and there are GitHub Actions workflows (codeql-analysis.yml) for security scanning. The structure shows ongoing multi-database support expansion (GBase adapter present). Specific PR/milestone data is not visible in the file list, but the presence of dependabot.yml indicates automated dependency management.

Clone the repository and inspect the .csproj files to determine your EF Core version and target database. For SQL Server: add NuGet reference to EFCore.BulkExtensions (targets the Core library). For other databases (PostgreSQL, MySQL, Oracle, SQLite), reference the appropriate package (EFCore.BulkExtensions.MySql, etc.). Run dotnet restore and dotnet build from the root or specific project directory.

Daily commands: No single 'dev server'—this is a library. To verify the build and run tests (if present): dotnet build EFCore.BulkExtensions.Core/EFCore.BulkExtensions.Core.csproj for the core library, or dotnet build at the repo root for all projects. To use in an application: install via NuGet (dotnet add package EFCore.BulkExtensions) and call extension methods like context.BulkInsertAsync(entities) or context.BulkUpdateAsync(entities).

• EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs — Primary extension entry point exposing BulkInsert, BulkUpdate, BulkDelete, BulkRead, and other bulk operations to DbContext.
• EFCore.BulkExtensions.Core/TableInfo.cs — Core metadata class that describes table structure, columns, keys, and properties—essential for all bulk operations.
• EFCore.BulkExtensions.Core/SqlAdapters/ISqlOperationsAdapter.cs — Abstract interface defining the contract for database-specific bulk operations; all database adapters implement this.
• EFCore.BulkExtensions.Core/SqlBulkOperation.cs — Central orchestrator that coordinates bulk operation execution, data preparation, and result handling across all databases.
• EFCore.BulkExtensions.Core/BulkConfig.cs — Configuration class controlling bulk operation behavior (batch size, timeouts, logging, transaction handling, etc.).
• EFCore.BulkExtensions.Core/Batch/IQueryableBatchExtensions.cs — Batch update/delete extensions for IQueryable; provides chunk-oriented CRUD alternative to bulk operations.
• EFCore.BulkExtensions.Core/SqlAdapters/SqlAdaptersMapping.cs — Registry mapping EF Core database providers to their corresponding adapter implementations (SqlServer, PostgreSQL, MySQL, Oracle, SQLite).

Add a Bulk Insert Operation

1. Create entity instances and collect in a list (EFCore.BulkExtensions.Tests/EFCoreBulkTest.cs)
2. Configure BulkConfig with desired options (BatchSize, BulkCopyTimeout, etc.) (EFCore.BulkExtensions.Core/BulkConfig.cs)
3. Call context.BulkInsertAsync(entityList, config) extension method (EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs)
4. Framework resolves database adapter via SqlAdaptersMapping (EFCore.BulkExtensions.Core/SqlAdapters/SqlAdaptersMapping.cs)
5. Adapter executes bulk copy operation (e.g., SqlBulkCopy for SQL Server) (EFCore.BulkExtensions.SqlServer/SqlAdapters/SqlServer/SqlServerAdapter.cs)

Add Support for a New Database Provider

1. Create new library folder: EFCore.BulkExtensions.YourDb/ (EFCore.BulkExtensions.MySql/EFCore.BulkExtensions.MySql.csproj)
2. Implement ISqlOperationsAdapter for your database (EFCore.BulkExtensions.Core/SqlAdapters/ISqlOperationsAdapter.cs)
3. Implement ISqlDialect for database-specific SQL syntax (EFCore.BulkExtensions.Core/SqlAdapters/ISqlDialect.cs)
4. Create IDbServer enum entry and concrete DbServer class (EFCore.BulkExtensions.Core/SqlAdapters/IDbServer.cs)
5. Register adapter in SqlAdaptersMapping (EFCore.BulkExtensions.Core/SqlAdapters/SqlAdaptersMapping.cs)
6. Add database-specific tests in EFCore.BulkExtensions.Tests/ (EFCore.BulkExtensions.Tests/EFCoreBulkTestOracle.cs)

Add a New Batch Operation

1. Design the operation logic as extension method on IQueryable<T> (EFCore.BulkExtensions.Core/Batch/IQueryableBatchExtensions.cs)
2. Use BatchUtil to chunk the data and create parameters (EFCore.BulkExtensions.Core/Batch/BatchUtil.cs)
3. Build the dynamic update/delete expression using LINQ or SQL (EFCore.BulkExtensions.Core/Batch/BatchUpdateCreateBodyData.cs)
4. Execute in chunks, respecting BulkConfig batch size (EFCore.BulkExtensions.Core/BulkConfig.cs)
5. Add comprehensive tests covering edge cases (EFCore.BulkExtensions.Tests/EFCoreBatchTest.cs)

Customize Bulk Operation Behavior

1. Instantiate BulkConfig and set desired properties (EFCore.BulkExtensions.Core/BulkConfig.cs)

Database driver presence required: bulk operations fail silently if the appropriate ADO.NET provider (System.Data.SqlClient, Npgsql, MySqlConnector, etc.) is not installed. Connection string must support bulk operations (e.g., SQL Server requires TRUSTWORTHY or equivalent; check per-database docs). EF Core version mismatch with the installed NuGet package will cause runtime errors—always verify EFCore.BulkExtensions version matches your EF Core major version. Owned types and complex properties have special handling (see OwnedTypeUtil.cs)—modifying entity graphs without understanding this may silently skip owned entity bulk operations. Default BulkConfig uses transactions; nested transactions or existing transaction contexts can cause deadlocks (DbContextBulkTransaction.cs manages this but requires careful usage). GraphUtil.cs contains recursive graph traversal for shadow properties—deep entity hierarchies or circular references may cause stack overflow or missed column mappings.

• BulkCopy (SqlBulkCopy protocol) — The core performance mechanism—BulkExtensions uses native database bulk-copy APIs (e.g., SQL Server's SqlBulkCopy, PostgreSQL's COPY) rather than row-by-row inserts, achieving 10-100x speedup on large datasets
• Dialect-specific SQL generation (SQL Server T-SQL vs. PostgreSQL vs. MySQL) — Each supported database has different SQL syntax and bulk operation capabilities; the SqlAdapters pattern and ISqlDialect interface abstract this so the same C# API works across all 5 databases without user code changes
• Entity metadata extraction via reflection (FastProperty, TableInfo) — Bulk operations must dynamically map EF entity properties to database columns at runtime; the FastProperty and TableInfo classes perform this mapping at scale without EF Core's full lazy-loading overhead
• Batch SQL generation (UPDATE WHERE / DELETE WHERE without materialization) — BatchUpdate and BatchDelete generate and execute single server-side UPDATE/DELETE statements from LINQ IQueryable predicates, avoiding the row-materialization and round-trip cost of standard EF Core SaveChanges()
• Graph traversal for entity relationships (GraphUtil, DbContextBulkTransactionGraphUtil) — When bulk-inserting parent-child entity hierarchies, the library must topologically order inserts and resolve foreign keys; GraphUtil performs graph analysis to handle navigation properties and owned types correctly
• Activity-based tracing and observability (ActivitySources.cs) — Bulk operations are long-running and opaque by default; ActivitySources provides OpenTelemetry integration so applications can trace, profile, and diagnose bulk operation performance in production
• Adapter pattern for database-agnostic operations (IDbServer, ISqlOperationsAdapter, ISqlDialect) — The library supports 5 different databases with minimal code duplication; the adapter pattern isolates database-specific logic (bulk copy mechanism, SQL syntax, transaction handling) behind interfaces, enabling parallel support

• dotnet/efcore — The upstream EF Core repository—BulkExtensions depends deeply on EF Core internals and adapts to each new EF Core major version release
• npgsql/npgsql — PostgreSQL ADO.NET data provider used by BulkExtensions' PostgreSQL dialect implementation
• mysql-net/mysql-connector-net — MySQL ADO.NET driver for MySQL bulk operations; understanding this provider's bulk API is required to extend MySQL adapter
• borisdj/EFCore.UtilExtensions — Sibling library by same author providing EF Core custom annotations and audit trails—commonly used alongside BulkExtensions for metadata-driven bulk operations
• MassTransit/MassTransit — Popular messaging framework often used with bulk operations to queue and batch large datasets asynchronously

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for SqlAdapters across all database providers

The repo supports 5 major databases (SQLServer, PostgreSQL, MySQL, Oracle, SQLite) with database-specific adapters (e.g., EFCore.BulkExtensions.MySql/SqlAdapters/MySql/, EFCore.BulkExtensions.PostgreSql/SqlAdapters/, etc.), but there's no visible test project in the file structure. Each adapter has dialect-specific query building logic (MySqlQueryBuilder.cs, OracleQueryBuilder.cs, etc.) that should be tested to prevent regressions when bulk operations behave differently across databases.

• [ ] Create EFCore.BulkExtensions.Tests project with xUnit/NUnit framework
• [ ] Add unit tests for SqlQueryBuilder implementations: MySqlQueryBuilder, OracleQueryBuilder, PostgreSqlQueryBuilder, testing edge cases like parameter escaping, MERGE vs INSERT/UPDATE syntax differences
• [ ] Add integration tests for BulkConfig.cs and TableInfo.cs with real database connections (use Docker containers in CI for PostgreSQL, MySQL, Oracle)
• [ ] Test dialect-specific implementations in SqlDefaultDialect.cs for each provider to ensure correct SQL generation

Implement GitHub Actions workflow for multi-database integration testing

The repo has .github/workflows/codeql-analysis.yml but no visible workflow for running tests against all 5 supported databases (SQL Server, PostgreSQL, MySQL, Oracle, SQLite). This is critical for a bulk operations library since behavior differs significantly per database. Contributors need confidence their changes work across all platforms before merging.

• [ ] Create .github/workflows/integration-tests.yml that runs on PR and push to main
• [ ] Set up Docker Compose services in the workflow for PostgreSQL, MySQL, and Oracle (SQLite doesn't need it)
• [ ] Run bulk operation tests against each database provider separately, with matrix strategy for EF Core versions
• [ ] Add test coverage reporting step and fail the workflow if coverage drops below threshold (especially for SqlAdapters folder)

Extract and document transaction handling abstractions in DbContextBulkTransaction.cs

The repo has DbContextBulkTransaction.cs, DbContextBulkTransactionGraphUtil.cs, and DbContextBulkTransactionSaveChanges.cs that handle complex transaction and change-tracking logic across different bulk operations. These files are critical but have no corresponding documentation or abstraction interfaces. New contributors cannot safely modify transaction handling without deep institutional knowledge.

• [ ] Review DbContextBulkTransaction.cs, DbContextBulkTransactionGraphUtil.cs, and DbContextBulkTransactionSaveChanges.cs to extract common transaction patterns
• [ ] Create ISqlTransaction interface in EFCore.BulkExtensions.Core/SqlAdapters/ to define transaction handling contract
• [ ] Add XML documentation comments to DbContextBulkTransaction.cs explaining transaction scope, isolation levels, and rollback behavior for each bulk operation
• [ ] Create TRANSACTION_HANDLING.md in repo root documenting how transactions are managed across bulk insert/update/delete and SaveChanges, with examples for each database provider

• Add integration tests for the Oracle adapter (EFCore.BulkExtensions.Oracle). The Core project has test patterns in Batch/ and Util/, but no .Test project is visible in the file list—creating a test suite validating Oracle-specific dialect behavior in OracleQueryBuilder and OracleAdapter would be high-value and isolated.
• Document the BulkConfig options with examples in the README or a CONFIGURATION.md file. The BulkConfig.cs class has many properties (BatchSize, UseTempDb, PropertiesToInclude, etc.) but their interaction and recommended values for different scenarios are not explained in the README snippet—a junior can write clear docs without deep code changes.
• Implement or expand progress reporting for batch operations. ProgressHelper.cs exists in SqlAdapters/ but there is no visible IProgress<T> integration in the Batch/* files—adding cancellation token and progress callback support to BatchUpdate and BatchDelete would improve UX and show control-flow patterns.

• High · SQL Injection Risk in Dynamic Query Building — EFCore.BulkExtensions.Core/SqlAdapters/SqlQueryBuilder.cs and database-specific query builders in SqlServer, PostgreSql, MySql, Oracle, SQLite, GBase adapters. The codebase contains multiple SQL adapter and query builder components (SqlQueryBuilder.cs, SqlServerQueryBuilder.cs, PostgreSqlQueryBuilder.cs, etc.) that construct SQL queries dynamically. Without visible evidence of parameterized queries or proper SQL sanitization throughout the query building process, there is a risk of SQL injection attacks when user input is incorporated into bulk operations. Fix: 1) Ensure all dynamic SQL construction uses parameterized queries exclusively. 2) Implement input validation and sanitization for table names, column names, and values. 3) Conduct thorough code review of all SqlQueryBuilder implementations. 4) Add security-focused unit tests covering SQL injection vectors.
• High · Insufficient Input Validation in Bulk Operations — EFCore.BulkExtensions.Core/BulkConfig.cs, EFCore.BulkExtensions.Core/TableInfo.cs, EFCore.BulkExtensions.Core/DbContextBulkExtensions.cs. The bulk operation methods (BulkInsert, BulkUpdate, BulkDelete) accept configuration objects (BulkConfig.cs) and table metadata (TableInfo.cs) without apparent comprehensive validation. Malicious or malformed input could bypass security controls or cause unexpected behavior. Fix: 1) Implement strict input validation for all BulkConfig properties. 2) Validate table and column metadata against actual database schema. 3) Enforce whitelisting of allowed operations and configurations. 4) Add bounds checking for batch sizes and timeout values.
• High · Potential Command Injection in Transaction Management — EFCore.BulkExtensions.Core/DbContextBulkTransaction.cs, EFCore.BulkExtensions.Core/DbContextBulkTransactionSaveChanges.cs. The DbContextBulkTransaction.cs and related transaction handling code may construct commands dynamically without sufficient validation. Complex transaction scenarios with user-controlled configuration could lead to command injection vulnerabilities. Fix: 1) Use parameterized commands for all database operations. 2) Implement comprehensive validation of transaction configuration. 3) Limit transaction control to safe, predefined patterns. 4) Add security logging for transaction operations.
• Medium · Missing Security Headers and Configuration Validation — EFCore.BulkExtensions.Core/BulkConfig.cs. No evidence of security-related configuration validation in BulkConfig.cs such as validation of database connection strings, encryption settings, or authentication parameters. This could allow insecure configurations to be used in production. Fix: 1) Add validation to ensure database connections use encrypted protocols (SSL/TLS). 2) Validate connection string security properties. 3) Require explicit opt-in for potentially dangerous operations. 4) Document security best practices for library usage.
• Medium · Insufficient Error Handling and Information Disclosure — EFCore.BulkExtensions.Core/BulkException.cs, throughout exception handling in all adapters. BulkException.cs and error handling throughout the codebase may expose sensitive information (table names, column structures, database internals) in exception messages that could be logged or displayed to users. Fix: 1) Implement generic error messages for production environments. 2) Log detailed errors securely server-side only. 3) Sanitize exception messages to exclude database schema information. 4) Implement structured logging with proper access controls.
• Medium · Missing Dependency Version Constraints — EFCore.BulkExtensions.Core.csproj, all *.csproj files. No provided dependency/package file content to verify. Without explicit dependency version pinning, the library could be vulnerable to attacks through compromised or outdated transitive dependencies, especially Entity Framework Core and database-specific drivers. Fix: 1) Pin all dependency versions explicitly. 2) Implement regular dependency scanning and updates. 3) Use tools like Dependabot (already configured) actively. 4) Maintain a Software Bill of Materials (SBOM). 5) Monitor NuGet security advisories.
• Medium · Lack of Rate Limiting and Resource Controls — undefined. Bulk operations can process large datasets without apparent built-in Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.