coder000

DDL to EF Core entities

Paste the CREATE TABLE statements of a PostgreSQL or SQL Server schema and get one C# file: an entity class per table and an AppDbContext with the keys, relationships, indexes, defaults and ON DELETE rules configured, so a migration generated from the model agrees with your database. Every choice that is not obvious is explained, and everything that needs your judgment is flagged.

Your DDL is converted on the server and forgotten. Nothing is stored, nothing is logged, and no database is contacted: the converter only reads the text.

Free API — use it from your own tools

The same engine powers an open API (this page uses it too). No signup, no key, just a rate limit of 60 requests per minute per IP. The API stores nothing.

curl

curl -X POST https://www.coder000.com/api/v1/ddl-to-efcore \
  -H "Content-Type: application/json" \
  -d '{"input": "CREATE TABLE rooms (id bigint PRIMARY KEY, name varchar(50) NOT NULL); CREATE TABLE doctors (id bigint PRIMARY KEY, room_id bigint REFERENCES rooms (id) ON DELETE SET NULL);"}' \
  | jq -r .output > AppDbContext.cs

Uniform response shape: { "output": "…", "notes": [...], "warnings": [...] }. output is the whole C# file as text, or null when no table was found. Each note and warning carries a change, an explanation and, where a post teaches the rule, a link. Send up to 100,000 characters per request.

How it works, and what it cannot do

No AI and no database. It is a mapping table, not a scaffolder: a rule-based reader goes through the CREATE TABLE, CREATE INDEX and ALTER TABLE … ADD statements, and each piece is translated by a fixed rule. bigint becomes long, varchar(200) a string with HasMaxLength(200), numeric(12, 2) a decimal with HasPrecision(12, 2), date a DateOnly, and a nullable column gets a ?. A single key column named Id, or PatientId on Patient, is left to EF Core's convention; any other key gets [Key], a composite key HasKey. Every foreign key gets navigations on both sides and a HasOne with an explicit OnDelete, because EF Core's default for a required relationship is Cascade, while a foreign key without ON DELETE means NO ACTION. A unique foreign key becomes a one-to-one. When the names are snake_case, the output leans on UseSnakeCaseNamingConvention() and only maps the names that convention would get wrong.

What it cannot know: what your code needs. Types it has no rule for (tsvector, vector, geography) become a string placeholder with a warning, expression indexes and index methods are left for a migration, and SQL in filters, defaults and CHECK constraints is copied in your DDL's dialect. The class and navigation names are guesses from the table and column names; rename them freely. For a database that already exists, dotnet ef dbcontext scaffold against the live database is the reference tool: it reads the real catalog instead of a script. This one is for the moment before that, when the schema is still a file.

One-to-many and ON DELETE Naming conventions and snake_case Npgsql and DateTime Kind Choosing column types Sibling tool: ER diagram from DDL Sibling tool: JSON to C# records