Podcast
Get Unstuck
A developer in our testing workshop was introducing tests to an existing project using SQL Server as the database engine. One of his constraints is that the database was managed outside the app, so there weren't any migrations to run in setting up the test database.
One proposed solution was to use the schema:dump command against the provided database, and then that dumped schema would work in place of migrations for the testing environment.
But if you run this command against a Microsoft SQL Server database, you will get an exception: "Schema dumping is not supported when using SQL Server."
Digging into it, I can see that this has been the case all the way back to the initial release of the schema:dump command in Laravel 8.
Why is this the case? Well, if we look at the other database implementations, we can see that each has a dependency on a specific set of executable files used to generate the schema dump.
For example, MySQL uses mysqldump, PostgreSQL uses pg_dump, and SQLite uses sqlite3.
Microsoft distributes its PHP driver for SQL Server without including any command-line tool like this, so I understand the decision to not support it.
My next thought was perhaps we could generate our own schema dump, place that in the same path that schema:dump would have used, and then we could still rely on it to bypass migrations.
This won't work either, because that migration logic is bypassed when using a SQLServerConnection.
It makes sense, since the other database engines also rely on the command-line tools to load the schema file.
So we're back to the same issue with SQL Server.
I believe you could build a SQL Server SchemaState implementation for Laravel that would only fail if the command-line tooling was not present on the system, instead of just failing globally.
Could be a fun project for you!
Here to help,
Joel
P.S. The testing workshop is not currently open for enrollment, but we will announce it on this newsletter when we re-open it in the near future.