sonot
/
PteroTheme
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Handle a plugin not properly namespacing itself and causing migration errors; ref #2291

This commit is contained in:
Dane Everitt 2020-09-01 20:24:25 -07:00
parent b707147b73
commit 631885d60c
No known key found for this signature in database
GPG Key ID: EEA66103B3D71F53
2 changed files with 34 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
database/migrations/2020_04_03_230614_create_backups_table.php
View File

@ -1,5 +1,6 @@
<?php <?php
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema; use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Migrations\Migration;
@ -13,6 +14,21 @@ class CreateBackupsTable extends Migration
*/ */
public function up() public function up()
{ {
$db = config('database.default');
// There exists a backups plugin for the 0.7 version of the Panel. However, it didn't properly
// namespace itself so now we have to deal with these tables being in the way of tables we're trying
// to use. For now, just rename them to maintain the data.
$results = DB::select('SELECT TABLE_NAME FROM information_schema.tables WHERE table_schema = ? AND table_name LIKE ? AND table_name NOT LIKE \'%_plugin_bak\'', [
config("database.connections.{$db}.database"),
'backup%'
]);
// Take any of the results, most likely "backups" and "backup_logs" and rename them to have a
// suffix so data isn't completely lost, but they're no longer in the way of this migration...
foreach ($results as $result) {
Schema::rename($result['TABLE_NAME'], $result['TABLE_NAME'] . '_plugin_bak');
}
Schema::create('backups', function (Blueprint $table) { Schema::create('backups', function (Blueprint $table) {
$table->bigIncrements('id'); $table->bigIncrements('id');
$table->unsignedInteger('server_id'); $table->unsignedInteger('server_id');

15
database/migrations/2020_04_26_111208_add_backup_limit_to_servers.php
View File

@ -1,5 +1,6 @@
<?php <?php
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema; use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration; use Illuminate\Database\Migrations\Migration;
@ -13,10 +14,24 @@ class AddBackupLimitToServers extends Migration
*/ */
public function up() public function up()
{ {
$db = config('database.default');
// Same as in the backups migration, we need to handle that plugin messing with the data structure
// here. If we find a result we'll actually keep the column around since we can maintain that backup
// limit, but we need to correct the column definition a bit.
$results = DB::select('SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = ? AND TABLE_NAME = \'servers\' AND COLUMN_NAME = \'backup_limit\'', [
config("database.connections.{$db}.database")
]);
if (count($results) === 1) {
Schema::table('servers', function (Blueprint $table) {
$table->unsignedInteger('backup_limit')->default(0)->change();
});
} else {
Schema::table('servers', function (Blueprint $table) { Schema::table('servers', function (Blueprint $table) {
$table->unsignedInteger('backup_limit')->default(0)->after('database_limit'); $table->unsignedInteger('backup_limit')->default(0)->after('database_limit');
}); });
} }
}
/** /**
* Reverse the migrations. * Reverse the migrations.