From d66371e2594ddc76504c2febc136f65f93f88768 Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Fri, 1 Nov 2024 23:02:13 -0400 Subject: [PATCH] Fix spelling mistakes --- blog/2024/11-02-efcore-refactoring-incoming/index.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/blog/2024/11-02-efcore-refactoring-incoming/index.mdx b/blog/2024/11-02-efcore-refactoring-incoming/index.mdx index 5bff2459a..4bedc3d4a 100644 --- a/blog/2024/11-02-efcore-refactoring-incoming/index.mdx +++ b/blog/2024/11-02-efcore-refactoring-incoming/index.mdx @@ -24,7 +24,7 @@ EFCore is the C#/.NET database handling framework, which simplifies database que Our original database code was written by Emby in a time long before .NET Core existed, when Mono ruled the world in terms of cross-platform C# compatibility. As such, it handled the database poorly: SQLite queries embedded directly in the code, and a fairly horrific schema with no migration capabilities. This has caused us a lot of problems over the years as we try to change and improve the codebase and add new features, and as such, the team began migrating to EFCore quite a while ago. -We were able to move many of the databases quickly, mostly due to the dilligent work of [@BarronPM](https://github.com/barronpm); those have been live for several major releases now. But the Library database has remained as it was, due to its massive complexity and exceptionally poor schema. This has caused a lot of probems, for instance very slow search, problems adding new media types (or deprecating old ones), and lots of complexity inside the codebase around handling "non-standard" (i.e. not Movies/TV Shows/Music Albums) media types, resulting in bugs. +We were able to move many of the databases quickly, mostly due to the diligent work of [@BarronPM](https://github.com/barronpm); those have been live for several major releases now. But the Library database has remained as it was, due to its massive complexity and exceptionally poor schema. This has caused a lot of problems, for instance very slow search, problems adding new media types (or deprecating old ones), and lots of complexity inside the codebase around handling "non-standard" (i.e. not Movies/TV Shows/Music Albums) media types, resulting in bugs. Now, thanks to [@JPVenson](https://github.com/JPVenson), we finally have the library database EFCore implementation ready to go. But there is a big catch. @@ -46,15 +46,15 @@ The downside of this is, though, that we might not be able to cleanly implement 2. About 1-2 weeks after this blog post, we will merge the Library EFCore migration into our `master` branch and begin preliminary testing. If you want to help here, you will have to [build Jellyfin from source](/docs/general/installation/source), and the more people who can help here the better! -3. About 2 weeks after merging, assuming everything looks generally OK, we will **reenable unstable builds for the general public**. At this point, all unstable builds will apply the initial migrations on startup. That will bring us to about 4 weeks (give or take a week) from the 10.10.0 release. +3. About 2 weeks after merging, assuming everything looks generally OK, we will **re-enable unstable builds for the general public**. At this point, all unstable builds will apply the initial migrations on startup. That will bring us to about 4 weeks (give or take a week) from the 10.10.0 release. -4. Over the following weeks, we will take bug reports and try to mitigte them. This is the possible sticking point: if it's not possible for us to implement a clean set of migrations, we may decide to only focus the migration on stable-to-unstable conversions, rather than unstable-to-unstable. If this happens, you may need to restore a previous version and apply the new migrations to it. +4. Over the following weeks, we will take bug reports and try to correct them. This is the possible sticking point: if it's not possible for us to implement a clean set of migrations, we may decide to only focus the migration on stable-to-unstable conversions, rather than unstable-to-unstable. If this happens, you may need to restore a previous version and apply the new migrations to it. ## What this actually means for you -First and foremost, if this is too much for you, this is your warning for the offramp. Switch away from unstable **now** before we restore the unstable builds in a few weeks. +First and foremost, if this is too much for you, this is your warning for the off-ramp. Switch away from unstable **now** before we restore the unstable builds in a few weeks. -Second, **ensure you have a robust backup strategy [based on our suggested backup process](general/administration/backup-and-restore)**. Take backups regularly, and, to help us test, try to also have a backup of your last stable release so you can run that through the migrations as well. Take backups **before** applying the next unstable build, every time. +Second, **ensure you have a robust backup strategy [based on our suggested backup process](/docs/general/administration/backup-and-restore)**. Take backups regularly, and, to help us test, try to also have a backup of your last stable release so you can run that through the migrations as well. Take backups **before** applying the next unstable build, every time. Third, **ensure you disable automatic upgrades**. We generally recommend this anyways, but if you're still doing this, now is the time to stop.