Frappe uses a metadata-driven approach for database management where DocTypes acts as schema definitions and database models. DocTypes define fields, relationships and behaviors directly, and changes are applied using the bench migrate command. This approach simplifies schema updates, integrates tightly with the framework and ensures version control through Git.<\/p>\n\n\n\n
Laravel manages database changes using Migrations, PHP files that programmatically define and modify database schema. Migrations are applied using Artisans commands like php artisan migrate and are version-controlled ensuring smooth updates across environments. This system offers flexibility enabling developers to handle schema changes and data seeding programmatically.<\/p>\n\n\n\n
<\/a>Database Management with Frappe\u2019s DocTypes<\/h2>\n\n\n\nFrappe\u2019s DocTypes (as covered previously in a previous article<\/a>) are the foundation of Frappe\u2019s database modelling system. They serve as a high-level abstraction for defining data structures and relationships in your application. Here are some key points about DocTypes.<\/p>\n\n\n\n\n- DocTypes define the structure of your data, including fields, their types and properties.<\/li>\n\n\n\n
- They automatically handle table creation, and schema updates in the underlying database.<\/li>\n\n\n\n
- DocTypes manage field properties such as validation, defaults and permissions.<\/li>\n\n\n\n
- They provide a user-friendly interface for developers to design and modify database schemas without writing SQL.<\/li>\n<\/ul>\n<\/div>\n\n\n
Frappe\u2019s approach to database management significantly reduces the need for manual migrations and makes changes seamless for developers.<\/p>\n\n\n
\n\n- When you create or modify a DocType, Frappe automatically updates the database schema.<\/li>\n\n\n\n
- Adding, modifying, or removing fields in a DocType is reflected in the database without manual intervention.<\/li>\n\n\n\n
- Frappe handles data type changes and creates necessary relationships and indexes automatically.<\/li>\n\n\n\n
- The framework manages relationships between DocTypes, creating foreign key constraints as needed.<\/li>\n\n\n\n
- Developers can focus on defining the data structure rather than writing complex migration scripts.<\/li>\n<\/ul>\n<\/div>\n\n\n
<\/a>Process of creating and modifying DocType<\/h3>\n\n\n\nIn the demo, we will be creating a DocType in Frappe and demonstrating automatic database changes. We will do this by creating a simple Customer<\/strong> DocType and then modify it to see how Frappe handles the database changes automatically.<\/p>\n\n\n\nStep 1: Creating the Customer DocType<\/strong><\/p>\n\n\n\n# This code would typically be part of a Frappe app setup\nfrom frappe import _\ndef get_customer_doctype():\n return {\n \"name\": \"Customer\",\n \"doctype\": \"DocType\",\n \"module\": \"CRM\",\n \"custom\": False,\n \"fields\": [\n {\n \"fieldname\": \"customer_name\",\n \"label\": _(\"Customer Name\"),\n \"fieldtype\": \"Data\",\n \"reqd\": 1\n },\n {\n \"fieldname\": \"email\",\n \"label\": _(\"Email\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Email\"\n },\n {\n \"fieldname\": \"phone\",\n \"label\": _(\"Phone\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Phone\"\n }\n ],\n \"permissions\": [\n {\n \"role\": \"System Manager\",\n \"read\": 1,\n \"write\": 1,\n \"create\": 1,\n \"delete\": 1\n }\n ]\n }<\/pre>\n\n\n\nThe _ functions in these lines in the previous code block are wrapping the string labels for various fields. This typically says that the code is prepared for internalisation(i18n), allowing the strings to be easily translated into different languages without modifying the core code structure.<\/p>\n\n\n\n
\"label\": _(\"Customer Name\"),\n\"label\": _(\"Email\"),\n\"label\": _(\"Phone\")<\/pre>\n\n\n\nWhen this DocType is created, Frappe will automatically:<\/p>\n\n\n
\n\n- Create a new table in the database called
`tabCustomer`.<\/code><\/li>\n\n\n\n- Add columns for
`customer_name`<\/code>, `email`<\/code>, and `phone`<\/code>.<\/li>\n\n\n\n- Set up appropriate data types and constraints (e.g.,
`customer_name`<\/code> as NOT NULL<\/code>).<\/li>\n<\/ul>\n<\/div>\n\n\nStep 2: Modifying the Customer DocType<\/strong><\/p>\n\n\n\nLet’s say we want to add a new field for the customer\u2019s address and modify the phone field to be required. We can update our DocType definition:<\/p>\n\n\n\n
def update_customer_doctype():\n return {\n \"name\": \"Customer\",\n \"fields\": [\n {\n \"fieldname\": \"address\",\n \"label\": _(\"Address\"),\n \"fieldtype\": \"Text\",\n \"insert_after\": \"email\"\n },\n {\n \"fieldname\": \"phone\",\n \"label\": _(\"Phone\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Phone\",\n \"reqd\": 1 # Making phone required\n }\n ]\n }<\/pre>\n\n\n\nWhen these changes are applied, Frappe will automatically:<\/p>\n\n\n
\n\n- Add a new
`address`<\/code> column to the `tabCustomer`<\/code> table.<\/li>\n\n\n\n- Modify the
`phone`<\/code> column to be NOT NULL<\/code> (required).<\/li>\n<\/ul>\n<\/div>\n\n\nAll these changes happen without the need for manual migration scripts, although Frappe still allows manual migration scripts when operations become too complex for the automatic system to handle efficiently which is termed \u2018patches\u2019 in Frappe.<\/p>\n\n\n\n
To create a manual migration script:<\/p>\n\n\n
\n\n- Create Python file in the `patches.txt` file of your Frappe app<\/li>\n\n\n\n
- Write your migration logic using Frappe\u2019s database API<\/li>\n\n\n\n
- Add the patch to your app\u2019s patch.txt file<\/li>\n\n\n\n
- Here\u2019s an example of a patch.<\/li>\n<\/ul>\n<\/div>\n\n\n
import frappe\ndef execute():\n # Your migration logic here\n frappe.db.sql(\"\"\"ALTER TABLE `tabCustomer` \n CHANGE `old_name` `new_name` VARCHAR(140)\"\"\")\n frappe.db.commit()<\/pre>\n\n\n\nWhile Frappe\u2019s automatic migration handles most common scenarios, these manual patches provide the flexibility to perform more complex database operations when needed.<\/p>\n\n\n\n
<\/a>Laravel\u2019s Migration System<\/h2>\n\n\n\nLaravel\u2019s migration system for managing database schema changes works in a version-controlled manner.<\/p>\n\n\n
\n\n- Migrations are like version control for your database, allowing you to define and share the application\u2019s database schema.<\/li>\n\n\n\n
- Each migration file contains a class with two methods: `up()` for applying the changes and `down()` for reverting them.<\/li>\n\n\n\n
- Migrations are typically stored in the `database\/migrations` directory of your Laravel project.<\/li>\n\n\n\n
- They are executed in the order of their timestamp prefixes, ensuring consistent application across different environments.<\/li>\n<\/ul>\n<\/div>\n\n\n
<\/a>Step-by-step Process of Working with Migrations<\/h3>\n\n\n\nThis is an overview of the process for creating a migration win Laravel\u2019s migration system.<\/p>\n\n\n
\n\n- Writing Migration Files:\n
\n- Use Artisan command to generate a new migration file:
`php artisan make:migration create_users_table`<\/code><\/li>\n\n\n\n- Define the schema changes in the
`up()`<\/code> method using Laravel’s Schema Builder.<\/li>\n\n\n\n- Implement the reverse of those changes in the
`down()`<\/code> method for rollbacks.<\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n- Running Migrations:\n
\n- Execute migrations using the Artisan command:
`php artisan migrate`<\/code><\/li>\n\n\n\n- This applies all pending migrations in chronological order.<\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n
- Rolling Back Migrations:\n
\n- Revert the last batch of migrations:
`php artisan migrate:rollback`<\/code><\/li>\n\n\n\n- Revert all migrations:
`php artisan migrate:reset`<\/code><\/li>\n\n\n\n- Rollback and re-run all migrations:
`php artisan migrate:refresh`<\/code><\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n- Versioning Changes:\n
\n- Migrations are automatically versioned by their timestamp prefixes.<\/li>\n\n\n\n
- Laravel keeps track of which migrations have been run in the
`migrations`<\/code> table.<\/li>\n<\/ul>\n<\/div><\/li>\n<\/ol>\n<\/div>\n\n\n <\/p>\n\n\n\n
This next diagram provides the overview of the process, and what follows will step you through the process.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2025\/01\/word-image-105336-1.png\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Let’s create a migration file to add a new `products`<\/code> table and explain how Laravel’s Artisan commands handle migrations.<\/p>\n\n\n\nStep 1: Generate the migration file<\/strong><\/p>\n\n\n\nphp artisan make:migration create_products_table<\/pre>\n\n\n\nThis command creates a new file in `database\/migrations`<\/code> with a name like `2023_12_24_123456_create_products_table.php`<\/code>.<\/p>\n\n\n\nStep 2: Define the schema changes<\/strong><\/p>\n\n\n\n<?php\nuse Illuminate\\Database\\Migrations\\Migration;\nuse Illuminate\\Database\\Schema\\Blueprint;\nuse Illuminate\\Support\\Facades\\Schema;\nclass CreateProductsTable extends Migration\n{\n \/**\n * Run the migrations.\n *\n * @return void\n *\/\n public function up()\n {\n Schema::create('products', function (Blueprint $table) {\n $table->id();\n $table->string('name');\n $table->text('description')->nullable();\n $table->decimal('price', 8, 2);\n $table->integer('stock')->default(0);\n $table->timestamps();\n });\n }\n \/**\n * Reverse the migrations.\n *\n * @return void\n *\/\n public function down()\n {\n Schema::dropIfExists('products');\n }\n}<\/pre>\n\n\n\nIn this migration:<\/p>\n\n\n
\n\n- The
`Illuminate`<\/code> is a core Laravel component which forms the foundation of the Laravel framework and provide much of its functionality.<\/li>\n\n\n\n- The
up()`<\/code> method creates a new `products`<\/code> table with columns for id, name, description, price, stock, and timestamps.<\/li>\n\n\n\n- The
`down()`<\/code> method drops the `products`<\/code> table, allowing for easy rollback.<\/li>\n<\/ul>\n<\/div>\n\n\nCreating a new table is a straightforward process in Laravel migrations. However, Laravel\u2019s migration system is capable of handling much more complex scenarios.<\/p>\n\n\n\n
For example: adding foreign keys and relationships.<\/p>\n\n\n\n
<?php\nuse Illuminate\\Database\\Migrations\\Migration;\nuse Illuminate\\Database\\Schema\\Blueprint;\nuse Illuminate\\Support\\Facades\\Schema;\nclass AddCategoryIdToProductsTable extends Migration\n{\n public function up()\n {\n Schema::table('products', function (Blueprint $table) {\n $table->unsignedBigInteger('category_id')->after('id');\n $table->foreign('category_id')->references('id')->on('categories')->onDelete('cascade');\n });\n }\n public function down()\n {\n Schema::table('products', function (Blueprint $table) {\n $table->dropForeign(['category_id']);\n $table->dropColumn('category_id');\n });\n }\n}<\/pre>\n\n\n\nThis migration adds a foreign key relationship between the `products`<\/code> and the `categories`<\/code> table.<\/p>\n\n\n\nStep 3: Run the migration<\/strong><\/p>\n\n\n\nTo apply this migration, run:<\/p>\n\n\n\n
php artisan migrate<\/pre>\n\n\n\nHow Laravel\u2019s Artisan commands handles migrations:<\/p>\n\n\n
\n\n- When you run
`php artisan migrate`<\/code>, Laravel checks the `migrations`<\/code> table in your database.<\/li>\n\n\n\n- It compares the migrations in this table with the files in your
`database\/migrations`<\/code> directory.<\/li>\n\n\n\n- Any migration files that haven’t been run (i.e., aren’t in the
`migrations`<\/code> table) are executed in order.<\/li>\n\n\n\n- For each migration, Laravel calls the
`up()`<\/code> method to apply the changes.<\/li>\n\n\n\n- After successful execution, Laravel adds a record to the
`migrations`<\/code> table, marking that migration as complete.<\/li>\n\n\n\n- If any errors occur during migration, Laravel will stop and rollback any changes made in that batch.<\/li>\n<\/ul>\n<\/div>\n\n\n
When you run php artisan migrate<\/code>, Laravel checks the `migrations`<\/code> table in your database. It compares the migrations in this table with the files in your `database\/migration`<\/code> directory. Any migration files that haven\u2019t been run(i.e., aren\u2019t in the `migration`<\/code> table) are executed in order.<\/p>\n\n\n\nFor each migration, Laravel calls the `up()`<\/code> method to apply the changes. After successful execution, Laravel adds a record to the `migration`<\/code> table, marking that migration as complete.<\/p>\n\n\n\nIf any errors occur during migration, Laravel will stop the process at that point. Any migrations that were successfully completed before the error will remain applied but no further migrations in that batch will be executed. This allows developers to fix the issue and continue the migration process.<\/p>\n\n\n\n
If you wanted to manually undo this migration:<\/p>\n\n\n\n
php artisan migrate:rollback<\/pre>\n\n\n\nThis command will call the `down()`<\/code> method of the most recent batch of migrations, effectively undoing the changes.<\/p>\n\n\n\nFor more granular control, Laravel also provides:<\/p>\n\n\n
\n\n`php artisan migrate:rollback --step=5`<\/code> to rollback the last 5 migrations.<\/li>\n\n\n\n`php artisan migrate:reset`<\/code> to rollback all migrations.<\/li>\n\n\n\n`php artisan migrate:refresh`<\/code> to rollback all migrations and then migrate again.<\/li>\n<\/ul>\n<\/div>\n\n\nLaravel’s migration system provides many ways to manage database schema changes, ensuring consistency across different environments and making it easier to work collaboratively on database-driven applications.<\/p>\n\n\n\n
<\/a>Comparisons of Database Flexibility and Control<\/h2>\n\n\n\nLet’s compare the database flexibility and control offered by Frappe’s DocType system and Laravel\u2019s migration system:<\/p>\n\n\n\n
- \n
- DocTypes define the structure of your data, including fields, their types and properties.<\/li>\n\n\n\n
- They automatically handle table creation, and schema updates in the underlying database.<\/li>\n\n\n\n
- DocTypes manage field properties such as validation, defaults and permissions.<\/li>\n\n\n\n
- They provide a user-friendly interface for developers to design and modify database schemas without writing SQL.<\/li>\n<\/ul>\n<\/div>\n\n\n
Frappe\u2019s approach to database management significantly reduces the need for manual migrations and makes changes seamless for developers.<\/p>\n\n\n
\n- \n
- When you create or modify a DocType, Frappe automatically updates the database schema.<\/li>\n\n\n\n
- Adding, modifying, or removing fields in a DocType is reflected in the database without manual intervention.<\/li>\n\n\n\n
- Frappe handles data type changes and creates necessary relationships and indexes automatically.<\/li>\n\n\n\n
- The framework manages relationships between DocTypes, creating foreign key constraints as needed.<\/li>\n\n\n\n
- Developers can focus on defining the data structure rather than writing complex migration scripts.<\/li>\n<\/ul>\n<\/div>\n\n\n
<\/a>Process of creating and modifying DocType<\/h3>\n\n\n\n
In the demo, we will be creating a DocType in Frappe and demonstrating automatic database changes. We will do this by creating a simple Customer<\/strong> DocType and then modify it to see how Frappe handles the database changes automatically.<\/p>\n\n\n\n
Step 1: Creating the Customer DocType<\/strong><\/p>\n\n\n\n
# This code would typically be part of a Frappe app setup\nfrom frappe import _\ndef get_customer_doctype():\n return {\n \"name\": \"Customer\",\n \"doctype\": \"DocType\",\n \"module\": \"CRM\",\n \"custom\": False,\n \"fields\": [\n {\n \"fieldname\": \"customer_name\",\n \"label\": _(\"Customer Name\"),\n \"fieldtype\": \"Data\",\n \"reqd\": 1\n },\n {\n \"fieldname\": \"email\",\n \"label\": _(\"Email\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Email\"\n },\n {\n \"fieldname\": \"phone\",\n \"label\": _(\"Phone\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Phone\"\n }\n ],\n \"permissions\": [\n {\n \"role\": \"System Manager\",\n \"read\": 1,\n \"write\": 1,\n \"create\": 1,\n \"delete\": 1\n }\n ]\n }<\/pre>\n\n\n\nThe _ functions in these lines in the previous code block are wrapping the string labels for various fields. This typically says that the code is prepared for internalisation(i18n), allowing the strings to be easily translated into different languages without modifying the core code structure.<\/p>\n\n\n\n
\"label\": _(\"Customer Name\"),\n\"label\": _(\"Email\"),\n\"label\": _(\"Phone\")<\/pre>\n\n\n\n
When this DocType is created, Frappe will automatically:<\/p>\n\n\n
\n- \n
- Create a new table in the database called
`tabCustomer`.<\/code><\/li>\n\n\n\n- Add columns for
`customer_name`<\/code>,`email`<\/code>, and`phone`<\/code>.<\/li>\n\n\n\n- Set up appropriate data types and constraints (e.g.,
`customer_name`<\/code> asNOT NULL<\/code>).<\/li>\n<\/ul>\n<\/div>\n\n\nStep 2: Modifying the Customer DocType<\/strong><\/p>\n\n\n\n
Let’s say we want to add a new field for the customer\u2019s address and modify the phone field to be required. We can update our DocType definition:<\/p>\n\n\n\n
def update_customer_doctype():\n return {\n \"name\": \"Customer\",\n \"fields\": [\n {\n \"fieldname\": \"address\",\n \"label\": _(\"Address\"),\n \"fieldtype\": \"Text\",\n \"insert_after\": \"email\"\n },\n {\n \"fieldname\": \"phone\",\n \"label\": _(\"Phone\"),\n \"fieldtype\": \"Data\",\n \"options\": \"Phone\",\n \"reqd\": 1 # Making phone required\n }\n ]\n }<\/pre>\n\n\n\nWhen these changes are applied, Frappe will automatically:<\/p>\n\n\n
\n- \n
- Add a new
`address`<\/code> column to the`tabCustomer`<\/code> table.<\/li>\n\n\n\n- Modify the
`phone`<\/code> column to beNOT NULL<\/code> (required).<\/li>\n<\/ul>\n<\/div>\n\n\nAll these changes happen without the need for manual migration scripts, although Frappe still allows manual migration scripts when operations become too complex for the automatic system to handle efficiently which is termed \u2018patches\u2019 in Frappe.<\/p>\n\n\n\n
To create a manual migration script:<\/p>\n\n\n
\n- \n
- Create Python file in the `patches.txt` file of your Frappe app<\/li>\n\n\n\n
- Write your migration logic using Frappe\u2019s database API<\/li>\n\n\n\n
- Add the patch to your app\u2019s patch.txt file<\/li>\n\n\n\n
- Here\u2019s an example of a patch.<\/li>\n<\/ul>\n<\/div>\n\n\n
import frappe\ndef execute():\n # Your migration logic here\n frappe.db.sql(\"\"\"ALTER TABLE `tabCustomer` \n CHANGE `old_name` `new_name` VARCHAR(140)\"\"\")\n frappe.db.commit()<\/pre>\n\n\n\n
While Frappe\u2019s automatic migration handles most common scenarios, these manual patches provide the flexibility to perform more complex database operations when needed.<\/p>\n\n\n\n
<\/a>Laravel\u2019s Migration System<\/h2>\n\n\n\n
Laravel\u2019s migration system for managing database schema changes works in a version-controlled manner.<\/p>\n\n\n
\n- \n
- Migrations are like version control for your database, allowing you to define and share the application\u2019s database schema.<\/li>\n\n\n\n
- Each migration file contains a class with two methods: `up()` for applying the changes and `down()` for reverting them.<\/li>\n\n\n\n
- Migrations are typically stored in the `database\/migrations` directory of your Laravel project.<\/li>\n\n\n\n
- They are executed in the order of their timestamp prefixes, ensuring consistent application across different environments.<\/li>\n<\/ul>\n<\/div>\n\n\n
<\/a>Step-by-step Process of Working with Migrations<\/h3>\n\n\n\n
This is an overview of the process for creating a migration win Laravel\u2019s migration system.<\/p>\n\n\n
\n- \n
- Writing Migration Files:\n
- \n
- Use Artisan command to generate a new migration file:
`php artisan make:migration create_users_table`<\/code><\/li>\n\n\n\n- Define the schema changes in the
`up()`<\/code> method using Laravel’s Schema Builder.<\/li>\n\n\n\n- Implement the reverse of those changes in the
`down()`<\/code> method for rollbacks.<\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n- Running Migrations:
\n- \n
- Execute migrations using the Artisan command:
`php artisan migrate`<\/code><\/li>\n\n\n\n- This applies all pending migrations in chronological order.<\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n
- Rolling Back Migrations:
\n- \n
- Revert the last batch of migrations:
`php artisan migrate:rollback`<\/code><\/li>\n\n\n\n- Revert all migrations:
`php artisan migrate:reset`<\/code><\/li>\n\n\n\n- Rollback and re-run all migrations:
`php artisan migrate:refresh`<\/code><\/li>\n<\/ul>\n<\/div><\/li>\n\n\n\n- Versioning Changes:
\n- \n
- Migrations are automatically versioned by their timestamp prefixes.<\/li>\n\n\n\n
- Laravel keeps track of which migrations have been run in the
`migrations`<\/code> table.<\/li>\n<\/ul>\n<\/div><\/li>\n<\/ol>\n<\/div>\n\n\n<\/p>\n\n\n\n
This next diagram provides the overview of the process, and what follows will step you through the process.<\/p>\n\n\n\n
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Let’s create a migration file to add a new
`products`<\/code> table and explain how Laravel’s Artisan commands handle migrations.<\/p>\n\n\n\nStep 1: Generate the migration file<\/strong><\/p>\n\n\n\n
php artisan make:migration create_products_table<\/pre>\n\n\n\n
This command creates a new file in
`database\/migrations`<\/code> with a name like`2023_12_24_123456_create_products_table.php`<\/code>.<\/p>\n\n\n\nStep 2: Define the schema changes<\/strong><\/p>\n\n\n\n
<?php\nuse Illuminate\\Database\\Migrations\\Migration;\nuse Illuminate\\Database\\Schema\\Blueprint;\nuse Illuminate\\Support\\Facades\\Schema;\nclass CreateProductsTable extends Migration\n{\n \/**\n * Run the migrations.\n *\n * @return void\n *\/\n public function up()\n {\n Schema::create('products', function (Blueprint $table) {\n $table->id();\n $table->string('name');\n $table->text('description')->nullable();\n $table->decimal('price', 8, 2);\n $table->integer('stock')->default(0);\n $table->timestamps();\n });\n }\n \/**\n * Reverse the migrations.\n *\n * @return void\n *\/\n public function down()\n {\n Schema::dropIfExists('products');\n }\n}<\/pre>\n\n\n\nIn this migration:<\/p>\n\n\n
\n- \n
- The
`Illuminate`<\/code> is a core Laravel component which forms the foundation of the Laravel framework and provide much of its functionality.<\/li>\n\n\n\n- The
up()`<\/code> method creates a new`products`<\/code> table with columns for id, name, description, price, stock, and timestamps.<\/li>\n\n\n\n- The
`down()`<\/code> method drops the`products`<\/code> table, allowing for easy rollback.<\/li>\n<\/ul>\n<\/div>\n\n\nCreating a new table is a straightforward process in Laravel migrations. However, Laravel\u2019s migration system is capable of handling much more complex scenarios.<\/p>\n\n\n\n
For example: adding foreign keys and relationships.<\/p>\n\n\n\n
<?php\nuse Illuminate\\Database\\Migrations\\Migration;\nuse Illuminate\\Database\\Schema\\Blueprint;\nuse Illuminate\\Support\\Facades\\Schema;\nclass AddCategoryIdToProductsTable extends Migration\n{\n public function up()\n {\n Schema::table('products', function (Blueprint $table) {\n $table->unsignedBigInteger('category_id')->after('id');\n $table->foreign('category_id')->references('id')->on('categories')->onDelete('cascade');\n });\n }\n public function down()\n {\n Schema::table('products', function (Blueprint $table) {\n $table->dropForeign(['category_id']);\n $table->dropColumn('category_id');\n });\n }\n}<\/pre>\n\n\n\nThis migration adds a foreign key relationship between the
`products`<\/code> and the`categories`<\/code> table.<\/p>\n\n\n\nStep 3: Run the migration<\/strong><\/p>\n\n\n\n
To apply this migration, run:<\/p>\n\n\n\n
php artisan migrate<\/pre>\n\n\n\n
How Laravel\u2019s Artisan commands handles migrations:<\/p>\n\n\n
\n- \n
- When you run
`php artisan migrate`<\/code>, Laravel checks the`migrations`<\/code> table in your database.<\/li>\n\n\n\n- It compares the migrations in this table with the files in your
`database\/migrations`<\/code> directory.<\/li>\n\n\n\n- Any migration files that haven’t been run (i.e., aren’t in the
`migrations`<\/code> table) are executed in order.<\/li>\n\n\n\n- For each migration, Laravel calls the
`up()`<\/code> method to apply the changes.<\/li>\n\n\n\n- After successful execution, Laravel adds a record to the
`migrations`<\/code> table, marking that migration as complete.<\/li>\n\n\n\n- If any errors occur during migration, Laravel will stop and rollback any changes made in that batch.<\/li>\n<\/ul>\n<\/div>\n\n\n
When you run
php artisan migrate<\/code>, Laravel checks the`migrations`<\/code> table in your database. It compares the migrations in this table with the files in your`database\/migration`<\/code> directory. Any migration files that haven\u2019t been run(i.e., aren\u2019t in the`migration`<\/code> table) are executed in order.<\/p>\n\n\n\nFor each migration, Laravel calls the
`up()`<\/code> method to apply the changes. After successful execution, Laravel adds a record to the`migration`<\/code> table, marking that migration as complete.<\/p>\n\n\n\nIf any errors occur during migration, Laravel will stop the process at that point. Any migrations that were successfully completed before the error will remain applied but no further migrations in that batch will be executed. This allows developers to fix the issue and continue the migration process.<\/p>\n\n\n\n
If you wanted to manually undo this migration:<\/p>\n\n\n\n
php artisan migrate:rollback<\/pre>\n\n\n\n
This command will call the
`down()`<\/code> method of the most recent batch of migrations, effectively undoing the changes.<\/p>\n\n\n\nFor more granular control, Laravel also provides:<\/p>\n\n\n
\n- \n
`php artisan migrate:rollback --step=5`<\/code> to rollback the last 5 migrations.<\/li>\n\n\n\n`php artisan migrate:reset`<\/code> to rollback all migrations.<\/li>\n\n\n\n`php artisan migrate:refresh`<\/code> to rollback all migrations and then migrate again.<\/li>\n<\/ul>\n<\/div>\n\n\nLaravel’s migration system provides many ways to manage database schema changes, ensuring consistency across different environments and making it easier to work collaboratively on database-driven applications.<\/p>\n\n\n\n
<\/a>Comparisons of Database Flexibility and Control<\/h2>\n\n\n\n
Let’s compare the database flexibility and control offered by Frappe’s DocType system and Laravel\u2019s migration system:<\/p>\n\n\n\n
- It compares the migrations in this table with the files in your
- The
- The
- Revert all migrations:
- Define the schema changes in the
- Use Artisan command to generate a new migration file:
- Writing Migration Files:
- Modify the
- Add columns for
- Create a new table in the database called