Support the ongoing development of Laravel.io →
posted 11 years ago
Database

I recently added a migration to my project to change the length of a varchar column. It looks like this:

<?php

use Illuminate\Database\Migrations\Migration;

class FixAppPhoneNumbers extends Migration {

	/**
	 * People like to use parenthesis, dashes and dots with their phone
	 * numbers, thus resulting in the string values being truncated in the
	 * database. I'm going to make all of the phone number fields larger to
	 * compensate.
	 *
	 * @return void
	 */
	public function up()
	{
		DB::statement('ALTER TABLE `rental_applications` MODIFY `phone` VARCHAR(20)');
	}

	/**
	 * Reverse the migrations.
	 *
	 * @return void
	 */
	public function down()
	{
		DB::statement('ALTER TABLE `rental_applications` MODIFY `phone` VARCHAR(10)');
	}

}

I ran the migration in my development environment and it worked fine. Then I ran PHPUnit and I got all errors (every single test). They all failed with the same error, specifically:

Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1 near "MODIFY": syntax error (SQL: ALTER TABLE `rental_applications` MODIFY COLUMN `phone` VARCHAR(20))

I do my tests in memory using SQLite, so I thought this might be related to the dropping of Doctrine DBAL, but I checked and I've got "doctrine/dbal": "~2.3" in my composer.json file under require-dev.

Any thoughts as to why the MODIFY query will run against MySQL in my dev environment and not SQLite in the testing environment? I'm not too familiar with SQLite. Is MODIFY not allowed?

Last updated 3 years ago.
0

I found out that there is no MODIFY in SQLite. So my question now becomes:

How do I deal with this situation? I want to continue to use migrations, but I also want to be able to test using SQLite.

Is it possible to specify an alternative set of migrations for testing purposes?

Last updated 3 years ago.
0

I've used something like this in the past, as ->after() isn't supported either in sqlite (what I remember)

if (App::environment() == 'testing') {
    // Testing specific code -- you know this will be SQLite
} else {
    // Anything else
}

This would mean you could 'hack' previous migrations, that outside of testing do the same as they do now. But set the varchar to 20 in sqlite.

And make the second migration (the actual change from 10 to 20 length) empty for SQLite, but work normally for anything else.

Hope this gets you a step further and if there's a better way. I'm sure someone will correct me.

Last updated 3 years ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

benharold benharold Joined 11 Feb 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2025 Laravel.io - All rights reserved.