Persistence schema modifications don't seem to update existing database

[UFOSmuggler]

Howdy,

I note ColorTheme is added here, and causes an unknown column error in my Librum server that existed before this change:

fail: Application.Common.Middleware.ExceptionHandlingMiddleware[0]
      Unknown column 'b.ColorTheme' in 'field list'
      MySqlConnector.MySqlException (0x80004005): Unknown column 'b.ColorTheme' in 'field list'

I suspect that this change should also exist in this file as it seems to be the primary schema definition (judging by the name, I know nothing at all about the framework at hand).

However I don't know if this would fix the issue. Is there currently a method of updating the database when starting a new version of the server? I manually created this column and all is now well.

Apologies if I shouldn't just be building out of the main branch or something. I couldn't see any already existing things that obviously address this issue.

[DavidLazarescu]

Thanks for reporting. The database should be migrated with the newest changes. You should be able to do this by running dotnet ef upgrade from src/Presentation, I don't have experience on how this behaves on docker though, it would be great if you could try it.

[UFOSmuggler]

Hi @DavidLazarescu,

Thanks for your advice mate. I have reverted my manual column creation to test, though it appears the docker image builds without containing a file path named "src/Presentation", however I assume this is meant to be the path from this repository. I attempted to run "dotnet ef upgrade" from a few seemingly likely locations in the default docker container without success:

librum-server@librum:/var/lib/librum-server$ dotnet ef upgrade
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'ef' does not exist.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

I then installed the SDK and cloned the repo into the docker container. Within the container I built the application using the SDK using the selfhosting instructions, and changed into the src/Presentation dir. I then tried using both the dotnet runtime (docker container default) and dotnet sdk dotnet binaries to run "ef upgrade", but I am told there is no application named "ef" or "dotnet-ef", depending upon whether I tried sdk or runtime dotnet binaries, similar to the error above. I also tried this in the default workdir of the docker container entrypoint (basically the contents of src/Presentation/build), with similar results.

I know nothing about dotnet, so I am unsure what the issue is, apologies if I'm just trying the wrong thing.

[kekonn]

In order to use the dotnet ef commands they have to be installed: dotnet tool install --global dotnet-ef

@DavidLazarescu This is can be risky, but perhaps in "production" mode (env check) you could automatically have EF apply the migrations on startup?

[DavidLazarescu]

In order to use the dotnet ef commands they have to be installed: dotnet tool install --global dotnet-ef

@DavidLazarescu This is can be risky, but perhaps in "production" mode (env check) you could automatically have EF apply the migrations on startup?

It might be reasonable to do so in self-hosted environments.

[DavidLazarescu]

Hi @DavidLazarescu,

Thanks for your advice mate. I have reverted my manual column creation to test, though it appears the docker image builds without containing a file path named "src/Presentation", however I assume this is meant to be the path from this repository. I attempted to run "dotnet ef upgrade" from a few seemingly likely locations in the default docker container without success:

librum-server@librum:/var/lib/librum-server$ dotnet ef upgrade
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'ef' does not exist.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

I then installed the SDK and cloned the repo into the docker container. Within the container I built the application using the SDK using the selfhosting instructions, and changed into the src/Presentation dir. I then tried using both the dotnet runtime (docker container default) and dotnet sdk dotnet binaries to run "ef upgrade", but I am told there is no application named "ef" or "dotnet-ef", depending upon whether I tried sdk or runtime dotnet binaries, similar to the error above. I also tried this in the default workdir of the docker container entrypoint (basically the contents of src/Presentation/build), with similar results.

I know nothing about dotnet, so I am unsure what the issue is, apologies if I'm just trying the wrong thing.

Can you confirm that the issue is fixed when you apply the migrations manually (running dotnet ef database update from src/Presentation)? (Make sure to download the .net tools)

[paulcsiki]

I have performed a clean installation of Librum on a kubernetes cluster and the application has started but it has only created the AspNetRoles and AspNetUsers tables (and has seeded them with the two roles and built-in user).

[paulcsiki]

This seems to be related to the fact that the migrations were generated using MSSQL and for self hosted you're using MySQL which has different data types and the CF migrations need to be regenerated. Edit: Deleting all the migrations, changing the folder description property data type to text using this code and then regenerating the migration and running it against the cluster database after cleaning all tables has worked. [Column(TypeName = "text")]

Additionally I've had to manually add a Product to login as it seems that it blows up beautifully otherwise. Seeding the admin user should have taken care of this.