2

We would like to programmatically ensure that a database table has a certain set of rows (based on a sometimes-changing enum). We are using EF Core 2.2 with code-first migrations and are looking for the right place to seed this data. We had thought that adding a seeding method to our Startup.cs would be a good idea, but Microsoft's documentation says

The seeding code should not be part of the normal app execution as this can cause concurrency issues when multiple instances are running and would also require the app having permission to modify the database schema.

Is the code in Startup.cs considered "part of the normal app execution"?

Our app currently only runs with 1 instance, but there might be multiple in the future. Plus, we have an Azure Functions app and a console app which might also need to ensure that the database table has the correct rows before executing. Despite these concerns, I have seen accepted and upvoted answers on other threads saying that initializing as part of Startup.cs is okay. Will we be shooting ourselves in the foot by doing this?

NSouth
  • 5,067
  • 7
  • 48
  • 83
  • if your enum changes every so often, it may be better to store it as a table in the db, or in as k/v in a key value table. – Jeff Apr 14 '20 at 01:06

1 Answers1

0

From the docs:

Depending on the constraints of your deployment the initialization code can be executed in different ways:

Running the initialization app locally.
Deploying the initialization app with the main app, invoking the initialization routine and disabling or removing the initialization app.

My interpretation from this is that you could deploy a console app using publishing profiles that ensured the database seed at launch.

Community
  • 1
  • 1
Jeff
  • 810
  • 8
  • 18