Add migrations for database setup

[linkdotnet]

Currently, the migration for the database has to be done manually. It would be nice if a BackgroundService does the initial database setup (instead of Database.EnsureCreated) and migration.

For starters, this could be an "SQL" only thing and incrementally also supported for RavenDB, if anyone uses this.

[manishtiwari25]

We can just add migrations and create a script (or something) to run the migrations, instead of adding it in a background job.

[linkdotnet]

We can just add migrations and create a script (or something) to run the migrations, instead of adding it in a background job.

You mean something in the direction of DbUp? So basically a bunch of SQL scripts that get executed via a CLI tool and or script.

I thought of that, but we might have to maintain scripts for MySQL/SqlServer/Postgres and so on... adding a new provider would mean, they have to backport those scripts to said provider.

The obvious choice would be EF.Migrations (at least for the SQL Part).

[Kamyab7]

I'm thinking of something like Json Taylor did in this repo
https://github.com/jasontaylordev/CleanArchitecture
if you take a look here
https://github.com/jasontaylordev/CleanArchitecture/blob/main/src/Infrastructure/Data/ApplicationDbContextInitialiser.cs
there is a class that can migrate the database automatically using EF.

[linkdotnet]

Yes exactly - that was my initial thought. Not sure whether or not that is really applicable here, as there aren't that many moving parts in the database (well, yesterday I merged a PR with a new field on BlogPosts with ReadingTimeInMinutes).

The advantage is that we would have one provider managing migrations (at least for the SQL part). Also we can write update-scripts in C#. If they really have to be executed on startup is a different topic and more or less a detail.

[Kamyab7]

We can make some searches to find best practices for reaching this goal also I'm thinking of some kind of strategy design pattern for handling the NoSQL part as well.

[linkdotnet]

Yeah - I'm also not very sure how much usage the NoSQL providers have and if the way forward would be dropping those. That would make the code way easier!

[Kamyab7]

Yeah - I'm also not very sure how much usage the NoSQL providers have and if the way forward would be dropping those. That would make the code way easier!

Good, I will create a pull request as soon as possible to tackle this issue.

[linkdotnet]

Much appreciated - yeah currently I am not sure if I can come to a conclusion. I would argue EF.Migrations might be a good way of kickstarting. Then at least one part would be covered.
Not the most urgent thing right now, but still nice to have.

[Kamyab7]

Hey Steven, I was a bit busy and now I'm trying to solve this issue.

I've been dealing with an issue recently and could use your insights. When attempting to add a new migration, I encountered a series of error messages. It seems like the culprit might be the editor config rules.

For instance, the generated migration file doesn't obey file scoped namespace

My initial thought was to have the .editorconfig ignore the migrations directories, but I'm not entirely sure if that's the most suitable solution. Have you come across any alternative approaches to address this issue? Your expertise would be greatly appreciated.

[linkdotnet]

Hey Kamyab, cool to hear back from you. Hope you are doing well!

To be honest I do think having a separate .editorconfig is suitable for that. It is basically 3rd party code so it doesn't have to follow the same rules as "our" code (and it may or may not change that at any point in time).
We already have different rules for .cs files that are under the tests directory. So that wouldn't be a novum here.

So yeah I would really go here with your intuition!

[Kamyab7]

Hey Kamyab, cool to hear back from you. Hope you are doing well!

To be honest I do think having a separate .editorconfig is suitable for that. It is basically 3rd party code so it doesn't have to follow the same rules as "our" code (and it may or may not change that at any point in time). We already have different rules for .cs files that are under the tests directory. So that wouldn't be a novum here.

So yeah I would really go here with your intuition!

Thanks Steven, It worked.
After several tests to make sure everything looks fine, I will create a pull request.