title | description | ms.date | ms.topic |
---|---|---|---|
Seed data in a database using .NET Aspire | Learn about how to seed database data in .NET Aspire | 08/12/2024 | how-to |
In this article, you learn how to configure .NET Aspire projects to seed data in a database during app startup. .NET Aspire enables you to seed data using database scripts or Entity Framework Core for common platforms such as SQL Server, PostgreSQL and MySQL.
Seeding data pre-populates database tables with rows of data so they're ready for testing via your app. You may want to seed data for the following scenarios:
- Manually develop and test different features of your app against a meaningful set of data, such as a product catalog or list of customers.
- Run test suites to verify that features behave a specific way with a given set of data.
Manually seeding data is tedious and time consuming, so you should automate the process when possible. Use volumes to run database scripts for .NET Aspire projects during startup. You can also seed your database using tools like Entity Framework Core, which handles many underlying concerns for you.
By default, .NET Aspire database integrations rely on containerized databases, which create the following challenges when trying to seed data:
- .NET Aspire destroys and recreates containers every time the app restarts, which means by default you have to re-seed your database every time the app restarts.
- Depending on your selected database technology, the new container instance may or may not create a default database, which means you might also have to create the database itself.
- Even if a default database exists, it most likely will not have the desired name or schema for your specific app.
.NET Aspire enables you to resolve these challenges using volumes and a few configurations to seed data effectively.
Volumes are the recommended way to automatically seed containerized databases when using SQL scripts. Volumes can store data for multiple containers at a time, offer high performance and are easy to back up or migrate. With .NET Aspire, you configure a volume for each resource container using the xref:Aspire.Hosting.ContainerResourceBuilderExtensions.WithBindMount%2A?displayProperty=nameWithType method, which accepts three parameters:
- Source: The source path of the volume mount, which is the physical location on your host.
- Target: The target path in the container of the data you want to persist.
Consider the following volume configuration code from a :::no-loc text="Program.cs"::: file in a sample AppHost project:
vartodosDbName="Todos";vartodosDb=builder.AddPostgres("postgres").WithEnvironment("POSTGRES_DB",todosDbName).WithBindMount("../DatabaseContainers.ApiService/data/postgres","/docker-entrypoint-initdb.d").AddDatabase(todosDbName);
In this example, the .WithBindMount
method parameters configure the following:
../DatabaseContainers.ApiService/data/postgres
sets a path to the SQL script in your local project that you want to run in the container to seed data./docker-entrypoint-initdb.d
sets the path to an entry point in the container so your script will be run during container startup.
The referenced SQL script located at ../DatabaseContainers.ApiService/data/postgres
creates and seeds a Todos
table:
-- Postgres init script-- Create the Todos tableCREATETABLEIF NOT EXISTS Todos ( Id SERIALPRIMARY KEY, Title text UNIQUE NOT NULL, IsComplete booleanNOT NULL DEFAULT false ); -- Insert some sample data into the Todos tableINSERT INTO Todos (Title, IsComplete) VALUES ('Give the dog a bath', false), ('Wash the dishes', false), ('Do the groceries', false) ON CONFLICT DO NOTHING;
The script runs during startup every time a new container instance is created.
The following examples demonstrate how to seed data using SQL scripts and configurations applied using the .WithBindMount
method for different database technologies:
Note
Visit the Database Container Sample App to view the full project and file structure for each database option.
The configuration code in the .AppHost:::no-loc text="Program.cs"::: file mounts the required database files and folders and configures an entrypoint so that they run during startup.
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.AppHost/Program.cs" range="37-49" :::
The entrypoint.sh script lives in the mounted ./sqlserverconfig
project folder and runs when the container starts. The script launches SQL Server and checks that it's running.
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.AppHost/sqlserverconfig/entrypoint.sh" :::
The init.sql SQL script that lives in the mounted ../DatabaseContainers.ApiService/data/sqlserver
project folder creates the database and tables.
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.ApiService/data/sqlserver/init.sql" :::
Configuration code in the .AppHost project:
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.AppHost/Program.cs" range="3-15" :::
Corresponding SQL script included in the app:
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.ApiService/data/postgres/init.sql" :::
Configuration code in the .AppHost project:
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.AppHost/Program.cs" range="20-32" :::
Corresponding SQL script included in the app:
:::code source="~/aspire-samples/samples/DatabaseContainers/DatabaseContainers.ApiService/data/mysql/init.sql" :::
You can also seed data in .NET Aspire projects using Entity Framework Core by explicitly running migrations during startup. Entity Framework Core handles underlying database connections and schema creation for you, which eliminates the need to use volumes or run SQL scripts during container startup.
Important
These types of configurations should only be done during development, so make sure to add a conditional that checks your current environment context.
Add the following code to the :::no-loc text="Program.cs"::: file of your API Service project.
// Register DbContext classbuilder.AddSqlServerDbContext<TicketContext>("sqldata");varapp=builder.Build();app.MapDefaultEndpoints();if(app.Environment.IsDevelopment()){// Retrieve an instance of the DbContext class and manually run migrations during startupusing(varscope=app.Services.CreateScope()){varcontext=scope.ServiceProvider.GetRequiredService<TicketContext>();context.Database.Migrate();}}
// Register DbContext classbuilder.AddNpgsqlDbContext<TicketContext>("sqldata");varapp=builder.Build();app.MapDefaultEndpoints();if(app.Environment.IsDevelopment()){// Retrieve an instance of the DbContext class and manually run migrations during startupusing(varscope=app.Services.CreateScope()){varcontext=scope.ServiceProvider.GetRequiredService<TicketContext>();context.Database.Migrate();}}
// Register DbContext classbuilder.AddMySqlDataSource<TicketContext>("sqldata");varapp=builder.Build();app.MapDefaultEndpoints();if(app.Environment.IsDevelopment()){// Retrieve an instance of the DbContext class and manually run migrations during startupusing(varscope=app.Services.CreateScope()){varcontext=scope.ServiceProvider.GetRequiredService<TicketContext>();context.Database.Migrate();}}
Database seeding is useful in a variety of app development scenarios. Try combining these techniques with the resource implementations demonstrated in the following tutorials: