Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade failing for MySQL with syntax error using v1.7.0 #513

Closed
twerthi opened this issue May 6, 2024 · 8 comments · Fixed by #515
Closed

Upgrade failing for MySQL with syntax error using v1.7.0 #513

twerthi opened this issue May 6, 2024 · 8 comments · Fixed by #515

Comments

@twerthi
Copy link

twerthi commented May 6, 2024

Describe the bug
grate-internal/01_version_add_status_column.sql: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IF NOT EXISTS status varchar(50) NULL' at line 2

An error occurred: Migration failed due to the following errors:

Update ("up"):

I switched to version 1.6.2 and it works fine.

To Reproduce
Use the grate Step Template in Octopus Deploy with the Download Grate option selected and not specify a version.

Expected behavior

Screenshots

Desktop (please complete the following information):

  • OS: Linux
  • Version: 22.04

Additional context

@erikbra
Copy link
Owner

erikbra commented May 7, 2024

Blargh! Sorry. This is probably the internal grate tables' migrations I have introduced that have errors. But, all my tests work fine. Which version of MySql are you running against?

Do you see any errors in the script that is registered in the Grate_Internal.ScriptRunErrors (or Grate.ScriptRunErrors?)

It's the script here (with the tokens replaced) that is run:

https://github.com/erikbra/grate/blob/main/src/grate.mariadb/Bootstrapping/Sql/GrateStructure/up/01_version_add_status_column.sql

@twerthi
Copy link
Author

twerthi commented May 7, 2024

Greetings Erik! I'm running against the latest MySQL container, mysql/mysql-server. I'm running grate using an Octopus Deploy step template, this is the command executed

Executing C:\Octopus\Work\Ta5sL6HFhUGfxOyhNbMb5g\grate\tools\net8.0\any\grate.dll with --connectionstring="Server=192.168.1.64;Port=30000;Allow User Variables=true; Uid=root;Pwd=****; Database=sakila_Development;" --databasetype=mariadb --silent --transaction=false --commandtimeout=60 --verbosity=information --version=1.0.24045.165919 

Did I miss something?

In regards to your question, where would I find that?

@twerthi
Copy link
Author

twerthi commented May 7, 2024

I just saw there was a new version of the template available which added the environment and schema inputs. I ran it again, but encountered the same error

Executing C:\Octopus\Work\Duh4YIXn10C1StO6tHnw\grate\tools\net8.0\any\grate.dll with --connectionstring="Server=192.168.1.64;Port=30000;Allow User Variables=true; Uid=root;Pwd=****; Database=sakila_Development;" --databasetype=mariadb --silent --transaction=false --commandtimeout=60 --verbosity=information --version=1.0.24045.165919 --environment=Development --schema=grate

I also tested

  • MariaDB
  • Postgres
  • SQL Server

All of those work fine.

@erikbra
Copy link
Owner

erikbra commented May 7, 2024

A quick follow-up question, @twerthi - could you issue be related to #512 ? Are you using custom "Create database" scripts?

@twerthi
Copy link
Author

twerthi commented May 7, 2024

I think it could be related, the database is created without the use of grate.

@erikbra
Copy link
Owner

erikbra commented May 7, 2024

If it is not created using grate, I don't think it's related.

It looks like it might be a difference in supported syntax in MariaDb vs MySQL:

MariaDb seems to support ADD COLUMN IF NOT EXISTS: https://mariadb.com/kb/en/alter-table/
MySQL doesn't seem to support it: https://dev.mysql.com/doc/refman/8.0/en/alter-table.html

I'll have to think a bit on how to solve this... we might rephrase the script that adds the status column to just add it, and ignore any errors if the column exists already.

I'm sceptical to remove the script, as any existing RoundhousE installations will have the version table, but the status column won't be there, so, we'd have to add a manual migration step, then.

erikbra added a commit that referenced this issue May 7, 2024
…ISTS' in internal grate tables

* Renamed MariaDb GrateStructure/up/01_version_add_status_column.sql to 01b_version_add_status_column.sql
  to avoid issues with changed one-time scripts (actually running it is idempotent)
erikbra added a commit that referenced this issue May 7, 2024
…ISTS' in internal grate tables

* Renamed MariaDb GrateStructure/up/01_version_add_status_column.sql to 01b_version_add_status_column.sql
  to avoid issues with changed one-time scripts (actually running it is idempotent)
erikbra added a commit that referenced this issue May 7, 2024
…ISTS' in internal grate tables (#515)

* Fixed syntax so that it is MySQL compatible
* Renamed MariaDb GrateStructure/up/01_version_add_status_column.sql to 01b_version_add_status_column.sql
  to avoid issues with changed one-time scripts (actually running it is idempotent)

fixes #513
@twerthi
Copy link
Author

twerthi commented May 8, 2024

Closing the loop, confirmed the new version is working fine :)

@erikbra
Copy link
Owner

erikbra commented May 8, 2024

Great, thanks for confirming, @twerthi !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants