I'm wondering how I am supposed to handle "partial" seeding.
Example, I have a "settings" table for the applications settings and these are populated on the initial seed, and down the road I need to add new settings. Is there a way to seed new data into the database or can seeding only be done on a fresh database?
If the latter, would the correct way to do this be to populate data through a migration?
Thanks.
You can try to use --class option to seed only settings, for example:
php artisan db:seed --class=SettingsTableSeeder
Related
On a part of a website I am making, I want to have a table for the website's information (About Us Page). To do this, I need to have a table that can only have one row. How can I limit the Laravel migration for this?
As far as I understand you want to have a database table with only and exactly one row, and you want to make that limitation with a Laravel Migration? As far as I'm aware there is no such limitation in Laravel, but if you are just trying to populate the table with one row you could set up a seeder:
php artisan make:seeder UserSeeder
and then run the seeder with the following command:
php artisan db:seed
You can find all the information in the docs here: https://laravel.com/docs/9.x/seeding
Hello everyone
I'm going to try to explain my problem as clear as possible, feel free to ask me more precision if you didn't understand what I meant and forgive my mistakes, English is not my mother tongue.
My goal
I want to start using migrations again because I need to create a new table, after a year where developers of my company bypassed them by creating/deleting/updating tables directly from phpmyadmin.
The things you have to know
The last migration was a year ago, but many tables have been created without migrations since that time.
Why I need your help
I'd like to know what is the best way to start using again migration without losing data or tables, because I'm working on an environment production.
What is the best way to do that ? Keeping the migrations that already exists and just ignoring the tables that have been created ? Deleting all migration files and deleting all the row in the migration table ?
If I delete all the migration files and truncate the migration table, will a php artisan migratewill have any impact on the existing schema ?
What is the best practice ? Should I recreate all the migrations of all the tables of my schema ? Or should I create only one migration with the new table I want to create ?
You could start from scratch by deleting all migrations and truncating the migrations table.
Then take a look at this post to recreate all the migrations for your current database schema.
Laravel keeps track of the migrations using a dedicated table that records when they were applied. When any one migration gets run, it inserts a new record in the table, and if you roll back a migration the corresponding record is deleted. You can therefore prevent undesired migrations from being run by adding them to this table.
My advice would be as follows:
Create the missing migrations
Run them on your local copy to get the database in the required state there
Export the migrations table
Import it to the production database
If you have any additional migrations you want to run after the ones you ran locally, run them in production
I'd definitely be careful to have a dry run beforehand though - perhaps after exporting the migrations, import the production database to your local copy, then import the migrations, and check it there.
I'd also be inclined to take steps to stop people applying changes to the production database directly - it's a very dangerous step that avoids accountability and makes it hard to test your application locally. Perhaps lock down PHPMyAdmin.
Mostly in these cases I try to sync migrations with my table so that I don't lose the current data which is on the database and I know that my migrations are updated .
So I from the first table whatever you have added in your table manually, you have to add that to your migration too .
In this case in future if you need to create a database truncate or anything else you know that your migrations are already up to date .
To be honest the best practice is to make the changes in your migration not in the database so you have not done the best practice so . this is the best practice that even can be done in your case so you make a migration to your project like this :
php artisan make:migration added_photo_to_user_table --table=users
and then in your migration :
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->text('photo')->nullable;
});
}
then u have to run the command
php artisan migrate
but in your case because you added the fields to the database you don't need to run the last command you just have to make migrations so in future if you want to make update to the database you do it as the best practice and you don't encounter any data lost .
I have a migration called CreateItemsTable; I ran that, I have items in that table, now I need to add a new field to the table. I can't just add a field to the migration file and migrate:refresh because I need the data that's in it.
Am I supposed to make another migration for adding a field? That's seems like mess while I'm testing things in development, I might change fields a lot. I'm not sure if migrations are cleaner than just PhpMyAdmin... or maybe I don't understand them?
Yes, each time you need to change a table in some way you'd create a new migration for it. That's the whole point of migrations. When you're developing in a collaborative environment and you pull down some changes from a remote repository, one of the things you should do (if working with a database) is run any migrations that other developers might have created. This keeps your databases in sync.
Sure you might drop and add columns occasionally but it's no big deal.
When you create a table for the first time you are probably using Schema::create(). All subsequent migrations for that table should use Scheme::table(). It accepts the same parameters except it doesn't attempt to create the table first.
I am totally new to FuelPHP, ORM and migrations in general so sorry if I come across like a newbie, but I've been struggling with this for a few hours now so I thought I'd ask for help. I think I'm either doing something wrong or missing something fundamental.
I am trying to create a users model, for simplicity let's say it just has a string representing name.
I was under the impression that using the following two Oil commands would create a users model, and an associated migration which after running would build an associated table:
php oil generate model user name:string
oil refine migrate
This does successfully create the model and migration, but running the second command doesn't build the table in the database.
If I run these commands on the other hand:
php oil generate migration create_user name:text
oil refine migrate
The migration is created and the table is built in my database. I noticed that perpending 'create_' to the migration name made it possible to create the table, whereas leaving it off (i.e php oil generate migration user name:text) doesn't insert the table to the DB. I noticed the generated migrations with and without the 'create_' are significantly different.
So my question ultimately is, how do I create the model, associated migration which creates the table? Or, am I totally misunderstanding something?
Thanks!
If you get 'Already on the latest migration', your migration tracking data is out of sync. Migrations are tracked both in the database (a table called migration) and a config file in your environment folder called migrations.php.
If there is already an entry in one of them, oil will not run it again.
So you can't just delete the table through the backdoor and then run the migration again. You'll have to run a 'migrate:down' to revert the last migration, or if you delete all, also delete the migration table and config file.
Again, credit to Harro Verton on the FuelPHP forums.
What is the best way to rebuild a model without loss data in MySQL for Symfony?
What if I have a big site, and a lot of data in the database and I would like after six months to add few new fields to database?
You can use migration.
Doctine manual
Symfony task for migrations
Slideshare presentation
Slideshare presentation
So you need write migrations, migrate, and build your models, forms, etc.
I suggest you use #denys281 for Symfony1.4 ....in Symfony2 however its VERY simple ... just use the command :
php app/console doctrine:schema:update --force
It compares what your database should look like (based on the mapping information of your entities) with how it actually looks, and generates the SQL statements needed to update the database to where it should be. In other words, if you add a new property with mapping metadata to Product and run this task again, it will generate the "alter table" statement needed to add that new column to the existing product table. So it doesnt remove any data
There is also a DoctrineMigrations bundle for Symfony2 if you fancy that route -> http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html