I have a create_users_table at the top and with foreign key to roles table but the location of roles table is at the bottom of create_users_table. So what happen is the create_users table can't see the roles table because it's not yet created. See attached image:
Do I need to recreate a users table so that it will come up below to roles table?
Do I need to recreate a users table so that it will come up below to
roles table?
You can't add a foreign key to a table that does not yet exist. If you want to manage your database through migrations, you do need to put them in the right order.
However, you can also add it as a separate migration, so that you have
create users table
create roles table
alter users table to add role_id field and foreign key
That way you don't have to rearrange existing migrations if you e.g. need to make changes to the database mid-project.
if its just a beginning of the project and if you are not using database migrations versioning yet you could just rename the datetime timestamp at migrations filename to rearrange the migrations. something like this would rearrange migrations to the required order. see i changed the year of 2016_08_13_001252_create_roles_table.php to 2014_08_13_001252_create_roles_table.php.
2014_08_13_001252_create_roles_table.php
2014_10_12_000000_create_users_table.php
2014_10_12_100000_create_password_resets_table.php
2016_08_08_005720_create_messages_table.php
migrations run in the datetime order of the filenames. Only the new migrations are run at each run. so, if you bring such changes to the files like renaming the file you need to drop database and create again, then run the migrations.
sometime after doing this you might need to run following commands in the project
composer dump-autoload and/or php artisan clear-compiled.
if you are running the migrations verisoning?
migrations are something related to databases and its not meant for dropping all the tables and recreating each and every time when you need to bring a change. If the database is live or if you have completed major database design you could use versioning. one of the purpose of migrations made in that way (datetime order and only new ones are migrated each time) is that only changes are brought to the old migrations created.
Related
Lets say I create a table in snowflake called Employee with EmployeeID and EmployeeName. I would check in the Create table script for this table to my github repo and get this deployed using sqitch. If in the next release, there is a need to add a new column to this table, can I accomplish this by just adding a new column to the existing Create table scripts. Does sqitch have the ability to compare github and my target DB to understand and generate ALTER scripts in this case?
Never mind, I did some more research and figured that Sqitch follows the imperative approach. Which means that it needs us to write the Alter statements in this case.
We are planning a major database restructure and instead of "Create" all the migrations are "Alter"-ing already existing tables.
For example:
There's table users that holds a column, e.g. role.
After running migrations this column will be dropped and table "Roles" will be created with a hasOne relationship (just an example).
How should I approach converting the old data into the new structure as seamlessly as possible?
It depends on the environment you are working in. for example in production level you can't just move those values from one column to another because the database Is heavily under usage of customers. but for instance you can create a migration to only create the roles table. then create a new migration to copy the corresponding role of each row to the newly created table(roles).
Roles
user_id | role_id
Users
id | role_id
After moving the whole role_id from users table to Roles table then you can push the new code implementation.
I don't really like the idea of removing the role_id column from users table immediately. i would suggest to keep that column for a while till you finish the whole changes related to that column then you can remove it safety without worry about it.
I have created database tables manually and i have also created foreign key constraints in tables manually without using migration. now when i am going to delete a record it giving me following error-
Integrity constraint violation: Cannot delete or update a parent row:
a foreign key constraint fails
Note: i can't use migration because database was already created.
Use ON DELETE CASCADE and ON UPDATE CASCADE on foreign keys, like:
...(create/alter Children table query)...
CONSTRAINT FK_ParentChild
FOREIGN KEY (parent_id) REFERENCES Parents(id)
ON UPDATE CASCADE ON DELETE CASCADE;
So you don't have to manually delete children before deleting the parent element. All children records will automatically delete along with the deletion of parent record.
I would suggest investigating this further by doing the follow:
On your development environment, write migrations to create the
tables from scratch 2)
Look at the generated schema and compare it
to the schema of your existing production tables
Note the
differences between the two schema and write migrations to correct
the production tables.
Note:
If you need to correct the data in the meantime and you are confident that the data integrity of your database is not at risk. You can use the following statements to drop the foreign key checks whilst you correct the data.
SET FOREIGN_KEY_CHECKS = 0;
SET FOREIGN_KEY_CHECKS = 1;
I can't stress enough, remember to turn on your foreign key checks once you are finished and do not do this on a production database. Take a copy of the database and try things locally until you are confident that your corrections are 100% safe ;)
I am working on such application where table audit should perform to make revision of updated records. Let's say for example I have to log each field update in Users update.
I wants to create clone of existing user table by
CREATE TABLE users_audit LIKE users;
My main question is,
Is there any alternative way or provision in Laravel migration to create table from existing table ?
I know we can run raw sql query in migration up/down method using \DB::raw();
But it would be helpful if any helper function available to create table from existing table like, create or table
Yes, you can, see the below link
Click this link
This statement is used to execute raw queries
DB::statement('CREATE TABLE tablename LIKE existingtablename');
I have table named "user_table" has certain columns and table has filled with data. I want to add some more columns. So how can I migrate that new schema in Laravel without loss of existing data. Even I can not do rollback because when I will do then all stored data will be deleted. So, can somebody please help me to solve this issue ?
You can create new table columns in migrations without loss of data. If you alter a column or drop a column, then of course you will manipulate existing data. As long as you are only adding new columns, then you can run
php artisan make:migration alter_my_table_add_columns
and update your existing schema. Then you can safely run
php artisan migrate
In your new migration you would then add:
Schema::table('my_table', function ($table) {
$table->string('my_new_column');
});
See: https://laravel.com/docs/master/migrations#creating-columns