@Sleeping-Dev this looks great and I'd like to accept but before I do, I wanna know a little more about what @skittlz444 is referring to. I usually never touch the migration files that dotnet ef migrations add ... creates but I'm assuming you are referring to this change?

protected override void Up(MigrationBuilder migrationBuilder)
        {
            migrationBuilder.AddColumn<decimal>(
                name: "ReleaseOrder",
                table: "Characters",
                nullable: false,
                defaultValue: 0m);
        }

replacing the

migrationBuilder.AddColumn<decimal>(
                name: "ReleaseOrder",
                table: "Characters",
                nullable: false,
                defaultValue: 0m);

to

migrationBuilder.Sql(
                name: "ReleaseOrder",
                table: "Characters",
                nullable: false,
                defaultValue: 0m);

When you do migrations like this, you usually have to wipe the database to scratch to add things. But does this prevent you from wiping the database over to make changes to your models?

migrationsBuilder.Sql(string command) allows you to run SQL Commands on the database as youre migrating, it's useful for situations like this, where we want to add additional columns and data to the database.

I believe what they meant was to do something along the lines of this:

migrationsBuilder.AddColumn<decimal>(
                name: "ReleaseOrder",
                table: "Characters",
                nullable: false,
                defaultValue: 0m);
migrationBuilder.Sql("<SQL COMMANDS FOR ADDING RELEASE ORDER TO EVERY ENTRY>");

so that when applying migrations, one wouldn't have to add the ReleaseOrder values manually. I'm thinking of solving this by just running an sql script ("addReleaseOrderValues.sql") that goes through each character entry and adds their respective ReleaseOrder value. It would look similar to "characters.sql", but of course just altering entries instead of adding new ones. In code it would look something like this:

migrationsBuilder.AddColumn<decimal>(
                name: "ReleaseOrder",
                table: "Characters",
                nullable: false,
                defaultValue: 0m);
migrationBuilder.Sql(File.ReadAllText("addReleaseOrderValues.sql"));

For this to work in prod I believe we'd need to add addReleaseOrderValues.sql to the publish directory like this:

In Smash_Combos.csproj:
<ItemGroup><Content Include="Models\addReleaseOrderValues.sql" CopyToPublishDirectory="PreserveNewest" /></ItemGroup>

Otherwise it won't be copied when deploying, then migrations can't be applied, etc. etc.

One drawback would be that this requires an additional .sql file to be added to prod. I could type the commands out by hand but that just... seems inefficient. On the other hand its just a one-time thing...

Thoughts on this?

Edit: Thinking about this more, I'll probably just type it out by hand. This really is a one time thing and adding an entire new file for just this migration feels very wrong. I'll check back in after work.

@Sleeping-Dev is right with what I meant. Since it is a once off, it usually is best to type it out into the migrate up method rather than adding a new file.

Alright, I'll write it up and commit after work 👍

I finished the update statements in the migration and am pretty much ready to commit. But when testing it I noticed that currently when setting up, it is still required to manually run psql Smash_ComboDatabase --file=Models/characters.sql as the characters are not added automatically during a migration.

I tested the migration by dropping and recreating the database, and as I forgot to run psql Smash_ComboDatabase --file=Models/characters.sql there were no characters for the current migration to update.

We could avoid this by automatically inserting the characters into the database during the AllTables-Migration I think?
That would remove the need to keep a characters.sql file and make the setup for other devs easier.

I don't think there's any problems with that, since I'm only adding Insert statements to an existing migration, right? That shouldn't impact databases that already have this migration applied, since those probably already have the data inserted anyway, so they're not missing out on any structural changes.

I went ahead and tried it out and it worked, couldn't find any problems! Basically what I changed:

• Changed the Migration name to something more accurate
• Added the data updates to the newest migration as we discussed. Instead of using migrationBuilder.Sql() I used migrationBuilder.UpdateData(), it looks a bit cleaner than a long string.
• Changed the ReleaseOrder for Yoshi in characters.sql from 6 -> 5, that was a typo from the last commit.
• Added the Character insertions from characters.sql into the Migration "AllTables", that way when setting up an environment for the app to run, there is no more need to run psql Smash_ComboDatabase --file=Models/characters.sql, as the characters are automatically inserted when running dotnet ef database update

characters.sql is now obsolete, as its only purpose was to fill the database with characters when setting up an environment, that now happens automatically, should be cleaner 👍

This probably could have been its own issue, but as I was editing migrations anyway I figured I'd just take care of it now, I'll split the commits up if necessary.

Thoughts?

@Sleeping-Dev Brilliant, I really like the changes to make running the characters sql obsolete. It all looks good, the only thing left to do is to update the contributions readme to reflect the changes of not needing to run characters sql anymore. Good work.

Wow @Sleeping-Dev, I'm still learning what you're doing here but this is awesome great job!

Thanks guys 👍
Alright, the documentation is updated and I also went ahead and deleted characters.sql while I was at it! @skittlz444 I think this should reflect your requested changes, feel free to approve this one.

Ty @Breadkenty, if you have any questions I'll gladly help, just message me on discord!