{{TOC}} **Миграции** - одна из наиболее моих любимых возможностей в Laravel. Я очень не люблю писать SQL - и класс %%Schema%% позволяет создавать нужные мне таблицы даже не вспоминая об этом пресловутом "языке программирования". Кроме того, код, использующей %%Schema%% очень красив и читается так же просто, как обычный связный текст. Если вы до сих пор не сталкивались с миграциями - это просто способ описать в одном файле изменения вашей базы данных - при этом разные установки или копии разработки проекта будут их учитывать. Изменения структуры могут быть //откачены// ("rolled back"). Кроме этого, миграции могут использоваться для заполнения таблиц начальными данными (это ещё называют "посевом" - "seeding"). == Настройка БД == Первым делом направляйтесь к файлу %%(t)application/config/database.php%% - если вы когда-либо устанавливали PHP-приложение, то вам знаком этот формат. У вас ведь есть данные подключения к вашей базе данных? Если нет - самое время их откопать! Ну что, вы вернулись? Отлично, продолжим. Прокрутите содержимое этого файла к массиву **connections** - здесь размещены настройки для различных типов баз данных. Внесите свои настройки в нужный тип, а я тем временем разберусь со своей старомодной MySQL: %% 'mysql' => array( 'driver' => 'mysql', 'host' => 'localhost', 'database' => 'codefun', 'username' => 'root', 'password' => 'pandaseatbamboo', 'charset' => 'utf8', 'prefix' => '', ), %% Вот и всё, теперь вам осталось прокрутить файл немного выше и установить ключ **default** в тип используемой БД - в моём случае это MySQL: %% 'default' => 'mysql', %% Наша БД сконфигурирована и теперь нам нужны таблицы, с которыми можно было бы поразвлечься. Впёрёд, к миграциям! == Миграции == Начнём с создания файла миграции. Для создания новой миграции нам понадобится интерфейс командной строки Laravel - "((док3:artisan/tasks Artisan))". Чтобы запустить его вам нужен установленный PHP (?CLI Command-Line Interface?) - обычно он идёт в комплекте с вёб-сервером. Откроем командную строку в папке установки Laravel (там, где содержится файл %%(t)artisan%%) и выполним нашу первую команду: %%(sh) php artisan migrate:make create_users %% Мы просим Artisan выполнить метод //make// задания //migrate//, которому мы передаём имя нашей миграции. Я обычно называю миграцию по действию, которое оно выполняет - в нашем случае мы будем создавать таблицу пользователей (%%(t)users%%). Посмотрим, что получилось: %%(t) Great! New migration created! %% Какой жизнерадостный ответ! Посотрим, что произошло в папке **application/migrations** - здесь появился новый файл %%(t)2012_03_30_220459_create_users.php%% - хотя ваш будет называться как-то иначе. Как вы уже заметили, Artisan добавляет к имени файла текущую дату и время в формате %%(t)His%% - причина этого в важности дат для миграций (как, впрочем, и для людей), потому что только так система может определить, в каком порядке они должны выполняться. Откроем появившийся файл и посмотрим, что он из себя представляет: %% class Create_Users { /** * Внести изменения в базу данных. * * @return void */ public function up() { // } /** * Отменить изменения базы данных. * * @return void */ public function down() { // } } %% Как вы видите, наш класс миграции содержит два метода: **up()** для изменения базы данных и **down()** для их отмены - благодаря ему миграцию можно применить, а затем //откатить// при необходимости. Например, если мы создаём таблицу в методе %%up()%%, то в %%down()%% нам нужно будет её удалить. Так как же нам внести изменения в нашу БД - наверное, не обойдётся без "красивых" SQL-запросов? На самом деле нет - ведь мы используем Laravel, поэтому если оно "красиво", то вы не найдёте этого во фреймворке. Посмотрим, как это делается при использовании класса **Schema**: %% Schema::create('users', function ($table) { // auto incremental id (PK) $table->increments('id'); // varchar 32 $table->string('username', 32); $table->string('email', 320); $table->string('password', 64); // int $table->integer('role'); // boolean $table->boolean('active'); // created_at | updated_at DATETIME $table->timestamps(); }); %% Мы вызываем метод **create()** класса %%Schema%% для создания новой таблицы - **первый параметр** указывает на её имя, а **вторым** передаётся //анонимная функция// ("closure"), где мы задаём её структуру. Функция принимает параметром объект создаваемой таблицы - вы можете назвать его как угодно, но я выбрал %%$table%%, потому что это самое логичное имя. Внутри функции мы можем использовать следующие красивые методы для определения структуры таблицы: * **increments()** - добавить автоинкрементируемое поле - его будет иметь бо(')льшая часть ваших таблиц * **string()** - создать поле %%(t)VARCHAR%% - правда, "строка" куда более описательное имя, чем в стандарте SQL? * **integer()** - добавить целочисленное поле * **float()** - поле с дробным числом (число с плавающей точкой) * **boolean()** - логическое ("булево") поле - //истина// (true) или //ложь// (false) * **date()** - поле даты * **timestamp()** - поле "отпечатка времени", так называемый "((WP:Unix timestamp==))" * **text()** - текстовое поле без ограничения по длине * **blob()** - //большой двоичный объект// (BLOB) К каждому из вызовов этих методов вы можете добавить %%->nullable()%% - тогда поле сможет принимать значение **NULL**. .(tl_note) Вы так же можете вызывать метод %%unsigned()%% для определения беззнакового числового поля. - //прим. пер.// Подробности об этих и других методах можно найти в ((док3:database/migrations документации)). Хорошо, мы создали таблицу в методе %%up()%% - теперь нам нужно удалить её в методе %%down()%%, таким образом структура базы данных вернётся в прежнее состояние при //откате//. Как обычно, класс %%Schema%% содержит для этого специальный метод: %% Schema::drop('users'); %% Ничто не может быть проще этого. %%Schema%% также позволяет выполнять другие операции над базой данных - например, удаление //полей// таблицы (%%drop_column()%%), добавление //индексов// (%%unique()%% и другие), а также добавлять //внешние ключи// ("foreign keys"). Описание всех этих методов превратит статью в руководство по API, поэтому я не буду этого делать, ведь всё хорошо расписано на ((док3:database/schema официальной документации)) - если хотите, можете ознакомиться с ней позднее, а мы пока продолжим. Как насчёт того, чтобы //выполнить// нашу миграцию? Но перед этим давайте создадим таблицу **laravel_migrations**, в которой Laravel будет хранить информацию о применённых миграциях. У Artisan есть для этого специальная команда: %%(sh) php artisan migrate:install %% В результате мы увидим: %%(t) Migration table created successfully. %% Отлично! Теперь эта таблица создана и мы наконец можем выполнить саму миграцию - на этот раз просто используем имя //задания// без указания //метода//: %%(sh) php artisan migrate Migrated: application/2012_03_30_220459_create_users %% Замечательно! Теперь если мы посмотрим на нашу БД мы увидим, что таблица **users** была создана. Постойте - мы допустили ошибку! (На самом деле это не так, но мне хочется придать статье драматический окрас, к тому же мне нужна причина, чтобы продемонстировать //откат//). В таком случае давайте отменим изменения: %%(sh) php artisan migrate:rollback Rolled back: application/2012_03_30_220459_create_users %% Конечно, кроме создания таблиц вы можете делать и другие вещи - например, заполнять их начальными данными - подробности этого описаны в моей следующей статье "((50))"