docdiscipline's avatar

Laravel Seeders Give Errors At Random Spots

To be honest I don't know where to look anymore. My seeders used to work. Then I reinstalled Windows 10, WSL 2 and Docker Desktop. All my code was hosted in Git Repo's including the Docker-Compose.yml that is used to start a test environment.

Basically nothing changed, but since the reinstall the DB seeders give error's at different moments, sometimes they even work completely.

use App\Models\Product;
use App\Models\Photo;
use Illuminate\Support\Facades\Schema;
use Illuminate\Support\Facades\DB;

class DatabaseSeeder extends Seeder
{
    public function run()
    {
      Schema::disableForeignKeyConstraints();
      Photo::truncate();
      Product::truncate();
    }
}

Yet most of the time they fail on the second command in the seeder Photo::truncate(); saying:

Illuminate\Database\QueryException 
 
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'DBname.photos' doesn't exist (Connection: mysql, SQL: truncate table `photos`)

at vendor/laravel/framework/src/Illuminate/Database/Connection.php:822
818▕                     $this->getName(), $query, $this->prepareBindings($bindings), $e
819▕                 );
820▕             }
821▕ 
➜ 822▕             throw new QueryException(
823▕                 $this->getName(), $query, $this->prepareBindings($bindings), $e
824▕             );
825▕         }
826▕     }

i   A table was not found: You might have forgotten to run your database migrations. 

I build a minimal example with two tables that are connected through a foreign key and still most of the time the seeder crashes (still on the second command).

I tried different dockers containers for the PHP/Nginx and two different Mysql containers the default and the Debian one. The error keeps coming and I don't know where I should look any more. Does anyone have any ideas on what to try out and how to go about it to find what is the cause of this error?

Thank you

0 likes
8 replies
docdiscipline's avatar

I am starting to get desperate, I don't know where to look any more. I now also tried MariaDB container and still the same problem. I did notice that when I delete the folder where the DB files are stored in the Linux shell (that folder is mounted using volume:s) the tables are still in the database when the DB is recreated by a new Mysql/Mariadb container at initialization. I tried to not use the volumes: to see if the tables would disappear, they didn't. So somehow my database is persistent even when deleted and relocated... This seems like a problem by it self... Yet I am not sure it is related. Furthermore the a php artisan migrate:reset is successful, the errors are only at seeding time.

I ran the seeder a couple of times, that last time they where succesful (if I run them again I am sure there will be errors). here are the random break points I encountered:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`cake-shop`.`product_product_property`, CONSTRAINT `product_product_property_product_id_foreign` FOREIGN KEY (`product_id`) REFERENCES `product_products` (`id`))
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`cake-shop`.`product_prices`, CONSTRAINT `product_prices_product_id_foreign` FOREIGN KEY (`product_id`) REFERENCES `product_products` (`id`))
 SQLSTATE[42S02]: Base table or view not found: 1146 Table 'cake-shop.product_sales' doesn't exist (Connection: mysql, SQL: truncate table `product_sales`)
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`cake-shop`.`product_product_properties_property`, CONSTRAINT `product_product_properties_property_product_id_foreign` FOREIGN KEY (`product_id`) REFERENCES `product_products` (`id`))
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'cake-shop.product_product_properties_property' doesn't exist 

And on the next try all seeders finish successfully... To me it feels like a Database issue. Yet having changed DB containers and even switched from Mysql to Mariadb I have no idea what to do anymore... any thoughts on the persisting of the tables (even after actual deletion of the files) would also be more then welcome...

Ishatanjeeb's avatar

can you please share your Docker-Compose.yml file

1 like
docdiscipline's avatar

ofcourse:

services:
  mysql:
    #image: mysql:8.2.0
    image: mariadb
    environment:
      - MARIADB_ROOT_PASSWORD=test
      - MARIADB_DATABASE=cake-shop
      - MARIADB_USER=test
      - MARIADB_PASSWORD=test
      - MYSQL_ROOT_PASSWORD=test
      - MYSQL_DATABASE=cake-shop
      - MYSQL_USER=test
      - MYSQL_PASSWORD=test
    #entrypoint: ['/bin/sh', '-c', 'sed -i -e "/^skip-name-resolve/d" /etc/mysql/conf.d/docker.cnf && /usr/local/bin/docker-entrypoint.sh mysqld']
    #entrypoint: ['/bin/sh', '-c', 'sed -i -e "/^skip-name-resolve/d" /etc/my.cnf && /usr/local/bin/docker-entrypoint.sh mysqld']
    #entrypoint: ['/bin/sh', '-c', 'sed -i -e "/^skip-name-resolve/d" /etc/mysql/my.cnf && /usr/local/bin/docker-entrypoint.sh mariadbd']
    ports:
      - 3306:3306
    volumes:
      - '/home/cake/cake-shop/Runtime-Environment/tmp_db:/var/lib/mysql'
      - '/home/cake/cake-shop/Runtime-Environment/docker-compose-developers/mysql:/docker-entrypoint-initdb.d'
    networks:
      - cake-shop
    restart: always
    healthcheck:
        test: "/usr/bin/mysql --user=root --password=test --execute \"SHOW DATABASES;\""
        interval: 4s
        timeout: 40s
        retries: 10
  migrationsandtestseeders:
    image: serversideup/php:8.2-fpm-nginx
    volumes:
      - '/home/cake/cake-shop/Database/product:/var/www/html'
    networks:
      - cake-shop
    environment:
      - APP_DEBUG=true
      - DB_HOST=mysql
      - DB_PORT=3306
      - DB_USERNAME=test
      - DB_PASSWORD=test
      - DB_DATABASE=cake-shop
      - APACHE_DOCUMENT_ROOT=/var/www/html/public
    working_dir: /var/www/html
    entrypoint:  ["/bin/sh","-c"]
    command:
      - |
         composer update
         composer install
         cp .env.example .env
         php artisan key:generate
         php artisan config:cache
         php artisan route:cache
         php artisan migrate:reset
         php artisan db:seed
         tail -f /dev/null
    depends_on:
      mysql:
        condition: service_healthy
    links:
      - mysql
    healthcheck:
        test: "php artisan test"
        interval: 2s
        timeout: 20s
        retries: 10
networks:
  cake-shop:
    name: cake-shop.com
Tray2's avatar

Read the error messages, they point you towards the issue. You need to migrate the database , before you seed it.

I also suggest that you read this post on common SQL errors for Laravel developers

https://tray2.se/posts/sqlerrm

docdiscipline's avatar

@Tray2 hi, Thank you for your answer and time. Did you read the question or just scan the errors? If I am wrong I would like to know, but I checked the link you send and this is al true stuff as far as I can see, yet none of the answers touches on the randomness of the errors.

The problem is that every now and then it is successful but most of the times there is an error, and which error is completely random. The errors above are the once I got will running the seeders 6 times in a row, only the 6 time was it successful and that is strange since nothing changed and every table is truncated at the start of the seeders.

Also before I reinstalled my Windows 10, WSL, Debian and Docked Desktop everything worked peaches.

I feel it has something to do with the DB container config (or the config from my Docker( Desktop) ) since I just found out that DBeaver also doesn't show all the tables and all the content every time you refresh the amount of tables and the rows within them change...

Tray2's avatar

@docdiscipline The reason for the errors is that there are no tables or missing tables in the database, that means that, and the database doesn't just loose tables like that, you need to tell it to drop the table first.

I have to say that your docker file looks wrong. Why aren't you using Sail instead of rolling your own image?

this is the database config for sail

mariadb:
    image: 'mariadb:10'
    ports:
        - '${FORWARD_DB_PORT:-3306}:3306'
    environment:
        MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
        MYSQL_ROOT_HOST: "%"
        MYSQL_DATABASE: '${DB_DATABASE}'
        MYSQL_USER: '${DB_USERNAME}'
        MYSQL_PASSWORD: '${DB_PASSWORD}'
        MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
    volumes:
        - 'sail-mariadb:/var/lib/mysql'
        - './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
    networks:
        - sail
    healthcheck:
        test: ["CMD", "mysqladmin", "ping", "-p${DB_PASSWORD}"]
        retries: 3
        timeout: 5s

Or use Laragon since you are running Wind0ze

https://laragon.org/index.html

docdiscipline's avatar

@Tray2 Thx again for your info. The migrationsandtestseeders is part of a whole range of micro-services. These are in an CI/CD environment and work just fine over there (this I realized when you said I should look at Sail, since this was the base back in old times when this project got started).

The shared docker-compose.yml is to start a development environment.

The migrations are run automatically before the seeders as you can see above. they fininsh (most of the time) without any errors.

The tables are in the database at the time the errors are shown, this is checked both by running the show tables; in side the cake-shop DB and using DBeaver.

I really feel you are not reading my question and findings, I get that you feel this is a simple error. Yet hope that you will agree that the randomness is strange. Further more every thing works in CI/CD.

At this point I feel it has something to do with the fact that I can't seem to permanently remove the DB files. All the data returns when a new DB is created. Other option that I am not excluding is that there is some performance tweak needed for MySQL to run on this system.

I have excluded code or Laravel problems at this point.

Thank you again and I will keep digging.

docdiscipline's avatar

The fact that I thought the data returned was because I was working under the assumption that an error during seeding would be a breaking error. As it turns out seeding continues despite and error being thrown. This made that the data was in all the tables when I got an error during truncate().

This leaves performance issues in my mind. Which is strange since it use to work just fine. Thinking that Docker Desktop setting might be the problem.

Please or to participate in this conversation.