support structure.sql

[mscoutermarsh]

Currently, psdb:migrate errors for apps that use structure.sql for their schema.

Due to an SSL error with mysqldump. We likely need to modify some setting so that mysqldump passes the correct certificate when connecting.

[joeldrapper]

I’ve been running into this. It’s great to see you're already on it! 🙏

[mscoutermarsh]

Oh great! We've been struggling to recreate it consistently.

We tried this branch on one persons machine but it did not resolve it.

Could you share your mysqldump version?

[joeldrapper]

It’s 100% consistent on my machine. Happy to help out or even jump on a call if it would help. This is my version:

mysqldump  Ver 8.2.0 for macos14.0 on arm64 (Homebrew)

[mscoutermarsh]

Thank you! I now have it reproducing on my own laptop. A solution feels close. 😄

[joeldrapper]

@mscoutermarsh it seems to mostly work, but there’s an incompatibility with the structure.sql generated on the server which means you can't use it locally.

This is the error I’m getting

@@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED

My workaround for now is to:

1. Run migrations locally
2. Commit locally-generated structure.sql into version control
3. Run migrations on PlanetScale branch
4. Delete the structure.sql generated by PlanetScale.

[mscoutermarsh]

Which Rails version? Latest?

It should be skipping the dump step.

[mscoutermarsh]

Ah, I've found the problem. Will try to get a fix done soon.

[mscoutermarsh]

A fix for the schema dump has been released in 0.2.2. An env var is now set which can be used to disable the schema dump.

In config/application.rb you can add:

if ENV["DISABLE_SCHEMA_DUMP"]
  config.active_record.dump_schema_after_migration = false
end

[joeldrapper]

@mscoutermarsh this seems to work perfectly now. It does leave me wondering how anyone would notice drift between the local structure.sql file and the actual structure of production. Do you have any advice on detecting that?

[mscoutermarsh]

@joeldrapper great!

We've found schema drift to be pretty unlikely when using this flow. The top cause is people modifying production directly.
With Safe Migrations turned on in production, any changes outside of the branching flow are blocked.

The other common cause of schema drift in most Rails apps is failed production migrations (running halfway and failing). This isn't an issue either when using the branching flow since we run every schema change through vitess online DDL. It must be successful before we write to the schema_migrations table in prod.

So while it is unlikely because of the above. I think the best way to check would be to do the following:

1. create a branch
2. rails psdb:schema:load
3. Then check the branch page on planetscale for a diff. There shouldn't be one