Framework: drop and add column of a table in one migration

[skarolus]

Hi,

i have following issue:

When i am running the seeder

with the structure:

array (
        'address_id'         => 1,
        'userName'            => 'testUser'
    ),

and the migration:

public function up()
{
    Schema::table('users_models', function($table)
        {
            $table->dropColumn('secondName', 'hairColor');
            $table->integer('address_id')->unsigned();
        });
}

there is the error message:

table users_models has no column named address_id

I am using

• sqlite
• Laravel Framework version 4.0.6

When I split the migration, it works

public function up()
{
        Schema::table('users_models', function($table)
        {
            $table->dropColumn('secondName', 'hairColor');
        });

        Schema::table('users_models', function($table)
        {
            $table->integer('address_id')->unsigned();
        });
}

[robclancy]

That's weird. What happens if you put the integer stuff before dropping the column in the first example?

Also those should be 2 completely separate migrations anyway.

[skarolus]

The same error occurres.

[taylorotwell]

I would just use the work-around then. Probably has something to do with how the SQLite table is dropped when dropping columns because of SQLite limitations.

[schickling]

Hmm same issue here. Feels kinda odd to use the workaround...

[taylorotwell]

Just use the workaround. You're using the most expressive migration builder ever written in PHP for crying out loud.

—
Sent from Mailbox for iPhone

On Tue, Nov 12, 2013 at 2:55 AM, Johannes Schickling
[email protected] wrote:

Hmm same issue here. Feels kinda odd to use the workaround...

Reply to this email directly or view it on GitHub:
https://github.com/laravel/framework/issues/2694#issuecomment-28277335

[taylorotwell]

:smile:

[michel-slm]

Same here, was tearing my hair out until I found this bug report. Will try splitting the migration for now until there's a stable release

[joshuajabbour]

Just to be clear, the problem with the "workaround" is that it makes using packages with migrations completely unreliable. So package developers need to test on all supported databases, which they don't. Therefore, any developer using an alternative DB needs to test and fix any packages they use, in the process figuring out this confusing and non-obvious bug.

[stewartadam]

I just ran into this as well, it's really silly:

• You cannot add columns and drop columns in the same migration
• You cannot have multiple column drops in the same migration

It would appear it's okay with multiple renames though. The workaround is good to know, but the root cause should really be resolved.

[reinink]

For anyone else who runs into this issue, @stewartadam is correct, breaking the migrations up seems to solve it. I had this problem when I added two columns in the same migrations.

[erikhu]

hi i have a problem , when i migrate , its ok the tables but the fields no found , namely the colums no be , thnks somebody can helpme

[stewartadam]

@erikhu: the GitHub issue tracker is for reporting bugs in Laravel, for user support or troubleshooting please try a forum such as the one on laravel.io. Remember to be specific in the error you are receiving and what you have tried so far so that the community can best try to assist you in identifying the problem!

[erikhu]

@stewartadam thnks for the reply , i was solved my problem

[MikeHopley]

I ran into this bug today and was baffled for hours.

The workaround is fine. The problem is knowing about the workaround in the first place. As mentioned above, this is a landmine for packages too. This issue is not even mentioned in the Laravel docs.

This is really unfortunate. Expressive APIs are great, but not when they hide very unexpected buggy behaviour. Sqlite is widely used in the Laravel community for testing databases. This is a nasty case of leaky abstraction.

[denismarinov]

Well, what do we do if I have to modify 30+ columns. This workaround is just stupidly redundant.