Open DarkGhostHunter opened 1 month ago
Thanks for the PR on this. I just ran into this issue myself.
Regarding your comment:
Newer Laravel versions do create the SQLite database file when force migrating. Otherwise, it won't.
Do you know what version this started happening in?
I believe 9.x or 8.x, I'll have to see the blame.
Thanks!
If it goes back that far with Laravel, should we even merge this?
I was able to resolve my issue by having proper permissions on my Docker Volumes with Laravel 11. Once I had the correct permissions, the auomations worked perfectly and created my database.
Thanks!
If it goes back that far with Laravel, should we even merge this?
I was able to resolve my issue by having proper permissions on my Docker Volumes with Laravel 11. Once I had the correct permissions, the auomations worked perfectly and created my database.
9.31 https://github.com/laravel/framework/pull/44153
It doesn't go that far IMHO. In any case, I think older Laravel apps would benefit from this on staging and development, especially if you are on the path to upgrade.
This PR allows the container to start and create missing the SQLite databases set by the application.
It's part of the container
AUTORUN_LARAVEL
scripts. It runs before the migrations. Is opt-in by default, mostly because usually production apps run on non-SQLite but PR/preview/staging apps sometimes do spin SQLite for testing or pure convenience.The way it works is through the
AUTORUN_LARAVEL_TOUCH_SQLITE
environment value, which by default isfalse
:true
,1
ordefault
, it will pick the default connection.default, telescope, custom
, it will find the connection names, and create each database file.This is done by checking if the driver is
sqlite
and the file doesn't exist. If it's not SQLite, it fails. If the database file already exists, doesn't do anything.