英文:
Proper way to access migrations files building custom refresh/seed in Laravel
问题
Looking for a smarter way to do this. I have 4 migrations files (out of MANY dozen) that are related. I also have a seeder for these. Doing php artisan migrate:fresh --seed
takes a good 30-45 seconds each time (there are also a few dozen seeders) and I want to just drop my 4 tables and rebuild quickly while testing.
我正在寻找更智能的方法来执行此操作。我有4个迁移文件(在许多文件中),它们是相关的。我还有一个用于这些表的种子。每次运行 php artisan migrate:fresh --seed
都需要大约30-45秒(还有几十个种子),我希望只需快速删除我的4个表并在测试时重新构建。
I want to define this programmatically instead of with a CLI, so I made an artisan command:
我想以编程方式定义这个操作,而不是使用命令行,因此我创建了一个 artisan 命令:
/* routes/console.php */
Artisan::command('refresh-my-tables', function() {
$numbers = include __DIR__ . './../database/migrations/2023_05_03_175125_create_my_table_numbers_table.php';
$files = include __DIR__ . './../database/migrations/2023_05_08_160034_create_my_table_files_table.php';
$orders = include __DIR__ . './../database/migrations/2023_05_03_175124_create_my_table_orders_table.php';
$parent = include __DIR__ . './../database/migrations/2023_05_03_171245_create_my_table_table.php';
// These are ordered intentionally to deal with foreign key constraints
$numbers->down();
$files->down();
$orders->down();
$parent->down();
$parent->up();
$orders->up();
$files->up();
$numbers->up();
(new Database\Seeders\MyTableSeeder)->run();
});
Just need a simple php artisan refresh-my-tables
只需要一个简单的 php artisan refresh-my-tables
This feels... wrong. Specifically the include [long absolute filename]
. I had thought Laravel, in the past, had a way to hook into migrations by name (letting PSR-4 handle finding the classes), but now, php artisan make:migration
builds a file that returns an anonymous Migration
extended class.
这感觉...不对。特别是 include [长绝对文件名]
部分。我过去以为 Laravel 有一种通过名称连接到迁移的方式(让 PSR-4 处理查找类),但现在,php artisan make:migration
会生成一个返回匿名的扩展 Migration
类的文件。
All Google and SO searches just refer to artisan migrate
without acknowledging more complex edge-cases that, I can imagine, are quite common for sufficiently large projects. Is this the best (most Laravel-flavored) way to do this?
所有的 Google 和 SO 搜索只提到 artisan migrate
,没有提到更复杂的边缘情况,我可以想象,对于足够大的项目来说,这些情况可能是相当常见的。这是做这个操作的最佳(最符合 Laravel 风格的)方式吗?
英文:
Looking for a smarter way to do this. I have 4 migrations files (out of MANY dozen) that are related. I also have a seeder for these. Doing php artisan migrate:fresh --seed
takes a good 30-45 seconds each time (there are also a few dozen seeders) and I want to just drop my 4 tables and rebuild quickly while testing.
I want to define this programmatically instead of with a CLI, so I made an artisan command:
/* routes/console.php */
Artisan::command('refresh-my-tables', function() {
$numbers = include __DIR__ . './../database/migrations/2023_05_03_175125_create_my_table_numbers_table.php';
$files = include __DIR__ . './../database/migrations/2023_05_08_160034_create_my_table_files_table.php';
$orders = include __DIR__ . './../database/migrations/2023_05_03_175124_create_my_table_orders_table.php';
$parent = include __DIR__ . './../database/migrations/2023_05_03_171245_create_my_table_table.php';
// These are ordered intentionally to deal with foreign key constraints
$numbers->down();
$files->down();
$orders->down();
$parent->down();
$parent->up();
$orders->up();
$files->up();
$numbers->up();
(new Database\Seeders\MyTableSeeder)->run();
});
Just need a simple php artisan refresh-my-tables
This feels... wrong. Specifically the include [long absolute filename]
. I had thought Laravel, in the past, had a way to hook into migrations by name (letting PSR-4 handle finding the classes), but now, php artisan make:migration
builds a file that returns an anonymous Migration
extended class.
All Google and SO searches just refer to artisan migrate
without acknowledging more complex edge-cases that, I can imagine, are quite common for sufficiently large projects. Is this the best (most Laravel-flavored) way to do this?
答案1
得分: 1
The old way of doing things is still valid at the time of this writing and Laravel 10. You can refactor your anonymous classes to look like this instead:
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration
{
public function up()
{
Schema::create('users', function (Blueprint $table) {
...
}
}
public function down()
{
Schema::dropIfExists('users');
}
}
Then your calls would just instantiate that class and run its methods.
EDIT: If you are coming to this from the internet and this isn't working, be sure to also add the path to these migrations to your composer.json so the autoload knows it's there. "autoload":{... "classmap": ["database/migrations/"]}
英文:
The old way of doing things is still valid at the time of this writing and Laravel 10. You can refactor your anonymous classes to look like this instead:
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration
{
public function up()
{
Schema::create('users', function (Blueprint $table) {
...
}
}
public function down()
{
Schema::dropIfExists('users');
}
}
Then your calls would just instantiate that class and run its methods.
EDIT: If you are coming to this from the internet and this isn't working, be sure to also add the path to these migrations to your composer.json so the autoload knows it's there. "autoload":{..."classmap": ["database/migrations/"]}
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论