Как правильно добавлять дату при миграции в Laravel?

Question

[Дмитрий]

Здравствуйте, создал миграцию. В ней создаю таблицу и записываю начальными данными.

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateStocksTable extends Migration
{
    public function up()
    {
        Schema::create('stocks', function (Blueprint $table) {
            $table->engine = 'InnoDB';
            $table->charset = 'utf8';
            $table->collation = 'utf8_general_ci';

            $table->increments('id');
            $table->text('title');
            $table->longText('content');
            $table->timestamps();
        });

        DB::statement('INSERT INTO `stock` (`title`, `content`, `created_at`, `updated_at`) VALUES ('some title', 'some content', '2019-04-29 00:00:00', '2019-04-29 00:00:00')');
    }

    public function down()
    {
        Schema::dropIfExists('stocks');
    }
}

id не указываю, автоинкремент заполнится автоматически, если не указать дату то после придется заполнять вручную.
Правильно ли задавать дату в миграции строкой либо можно заполнять ее автоматически датой и временем миграции?

Comments

[Alex Wells]

Я не понимаю, откуда вы взяли эту дичь. Неужели нельзя было бо докам сделать?

[Дмитрий]

Alex Wells, я новичек в этом, как правильно делать?

[Arman]

Дмитрий, проблема в кавычках

[JhaoDa]

Дмитрий, пан Новичек, попробуйте начать читать документацию.

[Дмитрий]

JhaoDa, а как вам такой вариант, есть задача, ищу решение, и по конкретному заданию читаю документацию, мне так лучше заходит.

[JhaoDa]

Дмитрий, очень плохой вариант.

[Дмитрий]

JhaoDa, согласен, но моя основная специализация это фронтенд, поэтому я многих вещей не знаю в принципе. И когда читаю документацию не всегда понимаю о чем речь.

[Alex Wells]

Дмитрий, ну тогда и в бек не лезьте. Либо погружайтесь, либо просите бекендеров которые занимаются проектом что бы написали для вас.

Answer 1

[netrox]

Для записи начальных данных используются сидеры .
Для дат можно использовать :

Schema::create('stocks', function (Blueprint $table) {
            $table->engine = 'InnoDB';

            $table->increments('id');
            $table->string('title');
            $table->text('content');
            $table->dateTime('date')->default(DB::raw('CURRENT_TIMESTAMP'));
        });

Comments

[Дмитрий]

Спасибо за подсказку про seeder. Попробовал, отлично работает и очень удобно.

[Alex Wells]

Еще один пришел.. даже не знаю как это назвать.

Дмитрий даже не вздумайте.

[netrox]

Alex Wells, что не так ?

[Alex Wells]

netrox,

$table->engine = 'InnoDB';
            $table->charset = 'utf8';
            $table->collation = 'utf8_general_ci';

зачем? ИнноДБ и так дефолт, utf8 вообще использовать нельзя, только utf8mb4.
$table->dateTime('date')
у ларки есть created_at и updated_at, и у автора тоже. И дефолтить их через базу не нужно.
$table->timestamps();
Далее сам его инсерт. Почему не через модель елоквента/доктрину? Даже если нужно вставить триллиард записей, почему бы не поставить ? вместо его created_at, null вместо updated_at, обернуть в DB::raw и передать туда now()?

title типа text? должен быть string 99% вероятность
content типа longText? либо хватит text, либо вообще должен быть json - тоже скорее всего

Так что не так - почти все.

[netrox]

Alex Wells,

ИнноДБ и так дефолт, utf8 вообще использовать нельзя, только utf8mb4.

title типа text? должен быть string 99% вероятность
content типа longText? либо хватит text, либо вообще должен быть json - тоже скорее всего

С выделенным согласен(упустил при копи-пасте).

Далее сам его инсерт. Почему не через модель елоквента/доктрину? ?

Эту идею я не поддерживал.

у ларки есть created_at и updated_at, и у автора тоже. И дефолтить их через базу не нужно.

Они типа timestamp, у которого в отличии от datetime меньше дипазон и он зависит от временной зоны.

[Alex Wells]

netrox, меньше диапазон - да, но для created_at и updated_at пока-что подходит. Тут должны быть изменения на уровне mysql, либо на уровне фреймворка/eloquent'а, но фигачить свои велосипеды таким образом точно не нужно. Либо везде datetime, причем так, что бы совместимость с ->timestamps() сохранялась, либо нигде.