erikbra / grate

grate - the SQL scripts migration runner
MIT License
209 stars 40 forks source link

runAfterCreateDatabase are run even if database isn't created from scratch by grate #536

Closed franzvrolijk-tietoevry closed 4 months ago

franzvrolijk-tietoevry commented 5 months ago

Describe the bug Documentation states:

3. runAfterCreateDatabase (Anytime scripts).
This directory is only processed if the database was created from scratch by grate. 
Maybe you need to add user accounts or similar?

However, when running grate against a backup of an existing database (not created by grate, does not contain any grate tables):

Initializing connections.
Running grate v1.6.0 (build date 02/12/2024 21:11:54) against . - DbsBasicData.
Looking in *******\src\Database\DbsBasicData for scripts to run.
================================================================================
Setup, Backup, Create/Restore/Drop
================================================================================
Trying to check the database DbsBasicData database on .
Database DbsBasicData querying with result 1
================================================================================
Grate Structure
================================================================================
================================================================================
Versioning
================================================================================
 Migrating DbsBasicData from version 0.0.0.0 to 1.0.
 Versioning DbsBasicData database with version 1.0.
================================================================================
Migration Scripts
================================================================================
Skipping 'BeforeMigration', beforeMigration does not exist.
Skipping 'AlterDatabase', alterDatabase does not exist.

Looking for Run After Create Database scripts in "*******\src\Database\DbsBasicData\runAfterCreateDatabase".
--------------------------------------------------------------------------------
  Running '0001_Alter_Database_DbsBasicData.sql'.

After

Trying to check the database DbsBasicData database on . Database DbsBasicData querying with result 1

I would not be expecting

Looking for Run After Create Database scripts in...

The database was not created from scratch by grate, so why is it running the scripts in this folder?

To Reproduce

  1. Have an existing database with no grate tables
  2. Run grate (with scripts in runAfterCreateDatabase)

Expected behavior

I would expect grate to skip these scripts as the database already existed prior to the run.

Desktop

Additional context

Am I misunderstanding the documentation? Do the grate tables need to exist beforehand for grate to not run runAfterCreateDatabase-scripts?

In my case there are no other scripts (or folders) present than the ones in runAfterCreateDatabase.

Edgaras91 commented 4 months ago

I have the same issue. I have a RoundhousE database, running Grate did create the Grate tables (GrateScriptsRun etc), but even with them, grate.sqlserver is still trying to execute the runAfterCreateDatabase scripts. Logs:

nfo: Grate.Migration[0] Skipping 'AlterDatabase', alterDatabase does not exist.
info: Grate.Migration[0]
info: Grate.Migration[0] Looking for Run After Create Database scripts in "D:\Projects\database\Hercules.Database.Console\bin\Debug\net8.0/db/Accounts\runAfterCreateDatabase".
info: Grate.Migration[0] --------------------------------------------------------------------------------
info: grate.Migration.DbMigrator[0]   Running '0000.BaselineSchema.sql'.
fail: grate.Migration.DbMigrator[0] 0000.BaselineSchema.sql: Could not drop object '[redacted]' because it is referenced by a FOREIGN KEY constraint.
XelgoSett commented 4 months ago

Fased the same issue. Seems like spaces in default folder configuration brakes folder name comparison

src\grate.core\Configuration\FoldersConfiguration.cs. Line 40 image src\grate.core\Migration\GrateMigrator.cs. Line 159. image

erikbra commented 4 months ago

Yes, this just looks like a plain old bug. The name of the folder does not equal the name of this constant. The folder configuration is a bit messy, and due for a rewrite. But, I think I see the problem, and can provide a work-around for this now, with out re-writing the whole folder configuration right now.