Migration issues - MySQL vs SQLite

I've recently inherited a codebase and whilst there are some tests, I want to improve the setup. At the moment, tests run using the local dev DB - rather than a separate DB for testing. This just feels wrong, and is causing a couple of tests to fail depending on the state of local data.

The current database is MySQL. I'm want to use a SQLite database for running tests, however I'm running into some trouble with migrations.

There are some migrations that modify tables and are failing when run in an SQLite database - therefore preventing me from using SQLite for my tests.

At the moment, the only solution I come think of is to go back and edit the original migration that created the table and update that so it matches the result of the edit, and then delete the "edit" migration.

This does feel slightly wrong - are there any better solutions?

mabdullahsari

6 years ago

Level 16

The sole proper solution is to account for SQLite limitations in those migrations by altering them. However, I would not suggest to merge migrations if it is deployed to a staging/production environment. Local environment does not matter at all.

I also have to account for SQLite limitations very often, e.g. could not drop 2 columns in 1 single transaction so had to create two separate Schema::table blocks in the down method. The plus is ofcourse tests that run on multiple threads, which I will happily take.

tykus

6 years ago

Level 104

You could consider a migration generator to replace create fresh migrations which match exactly your current schema. I am not held to the migration history so often use this package to regenerate my migrations.

Please or to participate in this conversation.