search

linkdotnet / Blog

A blog (engine) completely written in C# and Blazor. It aims to be a simple use and easy to extend platform. Blogposts are written in Markdown and are rendered to HTML. This gives all the flexibility needed to express yourself but also have an easy way of creating posts in the first place.
https://steven-giesel.com/
MIT License
258 stars 50 forks source link

Add migrations for database setup #258

Open linkdotnet opened 11 months ago

linkdotnet commented 11 months ago

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 commented 6 months ago

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

linkdotnet commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.