Based on today's discussion with @Thanood and @JeroenVinke I realized that there still are a few things that need explanation (to an acute observer, that is).
My approach to the solution of the problem of how to continue evolving carmel-api is incomplete as I focused too much on how to define the data needed to seed the database and have not clearly pointed out how to create the database structure.
I used the ASP.NET Core - New Database as the guidance to create the database structure using the classes Component.cs, Sample.cs, ComponentTag.cs and SampleTag.cs in the models folder. This action resulted with the creation of the Migrations** folder.
I used the **samples.json as the definition of the data used to seed the database (via the manual process described before, more than once)
When making changes to the database, I only made the changes to the database seed (item 2 above), meaning that the content of the Migrations folder was constant so far.
Now, since we need to change the database structure in order to implement the two steps workflow designed to allow us the control over user edits, @JeroenVinke should decide whether he wants to use existing initial migration and build on top of that - or to delete the migrations folder and delete the database itself, basically starting from step 1 above.
Based on today's discussion with @Thanood and @JeroenVinke I realized that there still are a few things that need explanation (to an acute observer, that is).
My approach to the solution of the problem of how to continue evolving carmel-api is incomplete as I focused too much on how to define the data needed to seed the database and have not clearly pointed out how to create the database structure.
I used the ASP.NET Core - New Database as the guidance to create the database structure using the classes
Component.cs,Sample.cs,ComponentTag.csandSampleTag.csin the models folder. This action resulted with the creation of theMigrations** folder.I used the **samples.json as the definition of the data used to seed the database (via the manual process described before, more than once)
When making changes to the database, I only made the changes to the database seed (item 2 above), meaning that the content of the
Migrationsfolder was constant so far.Now, since we need to change the database structure in order to implement the two steps workflow designed to allow us the control over user edits, @JeroenVinke should decide whether he wants to use existing initial migration and build on top of that - or to delete the migrations folder and delete the database itself, basically starting from step 1 above.