-2

I am trying to fix the bug with my Laravel project build and want to understand what steps exactly are done by php artisan migrate command.

The project uses my custom package.

  1. I've created a migration in the package, which adds a new column to the existing table:
    public function up()
    {
        Schema::table('products', function (Blueprint $table) {
            $table->boolean('is_good_product')->default(0);
        });
    }

    public function down()
    {
        Schema::table('products', function (Blueprint $table) {
            $table->dropColumn('is_good_product');
        });
    }
  1. Then I put the tag to the package version in my project composer.json file
'package: dev-master#tag-number'

and ran composer update package to update .lock file.

3.1. If I run the 'php artisan migrate' command locally I see that the new migration runs and creates needed column.

3.2. But building the branch on the remote stage server says the following error.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'is_good_product' in 'where clause' (SQL: select `name` from `products` where `is_good_product` = 1)  

I see this error when trying to migrate, rollback, refresh, truncate the database. Only creating the column manually helps me do rollback and then migrate.

Why Connection.php file is looking for this column? Is the migration from the package was started but wasn't finished? Or what else could happen?

[Edit] In other words - why 'artisan migrate' command complains about unknown column of newly added migration file? (it if should run it and add the column). And how Connection.php file can know about the column if the migration didn't run (as column wasn't created)?

Image of the error message

  • I see that people downvoting my question. Maybe my explanation was not good enough so I added more details. – user3471696 Jul 21 '20 at 23:57
  • Have you tried checking whether the migration was really run on deploying to the remote server? The given query, running a `SELECT` for a specific ID, should usually not be run when performing migrations – Nico Haase Jul 22 '20 at 07:09
  • I posted and answer below some minutes ago that I found the reason - I used this column in SELECT query in on repository constructor. And I didn't know and still don't know why `migrate` command run the code in constructor before running the migrations. So I couldn't do any php artisan command, even cache:clear because of the query in the repository (prettus/l5-repository library is used) – user3471696 Jul 22 '20 at 07:16
  • Well, you could debug your application to check **why** that query is fired before any migration is run. Maybe you need to define your services as lazy? Maybe you need to check why the constructor of a service already uses the database? – Nico Haase Jul 22 '20 at 07:26
  • I agree with you, it would be very nice to debug it and find why, but I couldn't find where I should put a breakpoint if i run php artisan migrate command. How would you debug it? – user3471696 Jul 22 '20 at 07:34
  • Do a rollback first, such that your application is in the state that does not work on the remote server. Afterwards, set the breakpoint to the line indicated by the error message you have shown - that's why the file name and line number are printed in these messages ;) – Nico Haase Jul 22 '20 at 07:35
  • Rollback didn't work and any others commands too. The only Information I saw in the message included only Connection.php and PDOConnection.php files which are placed in the vendor directory and breakpoints there do not work. I added and image to the post to look at it :) – user3471696 Jul 22 '20 at 07:44
  • Why shouldn't breakpoints in the vendor directory work? I'm using that nearly every day – Nico Haase Jul 22 '20 at 07:45
  • Wow, it is a good question. I just wanted to try it again but even didn't find line 664 in Connection.php file in vendor because I see there only 94 and 121 for PDOConnection.php... Maybe I shout place breakpoint on index.php or something like that, but I didn't know that project files are used for running artisan commands. – user3471696 Jul 22 '20 at 07:53
  • By the way, thanks for the productive discussion :) – user3471696 Jul 22 '20 at 07:58
  • You're welcome. Even if this looks strange to others, my goal is always to enable others to learn ways of debugging rather than just pointing at solutions - through learning your tools, you can solve so much more problems on your own afterwards – Nico Haase Jul 22 '20 at 08:00

2 Answers2

0

The quick fix to your problem is:

public function down()

{    
   if (Schema::hasColumn('products', 'is_good_product'))

    {

        Schema::table('products', function (Blueprint $table)

        {

            $table->dropColumn('is_good_product');

        });

    }
}

The reason why you're getting Connection.php error is because it didn't found the column to drop it.

issam abbas
  • 347
  • 2
  • 9
  • Thank you for the quick reply! But why is is trying to drop the column on php artisan migrate command? I thought that up() function should be called first. – user3471696 Jul 21 '20 at 15:35
0

After a deep research I've found the reasons why migrate command didn't work. The problem was in one of my repository's constructor which called a function that uses the column. I didn't know that Laravel somehow run source code in repositories before running migrations. And I still want to find out steps which are done by migrate command.