I am using Propel for PHP and I want to create a diff task to create new tables.
The issue is this is inside an existing database with tables already existing. I don't want these tables to be managed by Propel. When doing the diff task, it looks at these tables. Anyway to ignore these tables during the diff process?
No, migration tasks are quite dumb at the moment. That's why you always need to review generated diff classes.
Related
I have a started project in Codeigniter. I thought I will use some part of already created sections of similar site. So I have copied the old database and started work.
On that time it has around 40+ tables and has thousands of rows of data.
Then after I setup my environment for this new project, several tables created and all of those used migrations. It's then setup in development environment, so other team members can also work on.
Now I found old users and lots of data that I copied from old project not required
I decided to remove all tables that is not required for current project.
And need to remove all users and related data that was actually came from old project. Now database has 49 tables and I need only around 10 tables for my current project.
Question is Should I use migration to clear an old database?
Should I use migration to remove thousands of old data that are mixed with development data.
Should I use migration to alter several tables where lots of column not required for my current project?
Please provide suggestions
.. Thanks
In Laravel, migrations are there to keep a track of the structure of the database.
If your old database is not defined in migrations, there is no point to create migrations to remove unused tables. You can clean them manually.
But if you have made migrations for that old DB, then you can create new ones to clean it up.
Anything related to the actual data in the database should be placed within seeders nor custom command (e.g. php artisan make:command CleanData)
The reason is that if you ever need to squash your migrations, you will lose any instructions related to data.
I am using cakephp 3.
I need to run a script for updating the database schema like adding a column or altering it.
I do not wish to use Migrations as it would require me to write scripts for every change.
Is there any other way to alter schema of the database if we are neither using migrations nor making changes to the database manually using cakePHP 3?
You could use the schema system for doing this, which I think would work fine for things like adding user-defined columns. But if you're looking for an easier way to do migrations, you'd need to put that schema-related code somewhere and keep track of which changes have already been made, and then you're basically just re-inventing migrations.
We have ported the YII Migrations to our application. But sadly due to lack of knowledge / missing req. we are stuck on how to manage migrations between multiple instances of the same database.
Our structure is based on the same database which has different data in it.
While all databases have separate MySQL connection instances and are exactly the same.
The problem we are having is that we need the structural migrations to affect all databases but the data migrations to be applied only to given DB.
Any suggestions how to achieve that?
My idea was that I create an migration instance per database, but I have no means to tell the single migrations apart. I was thinking to use global vars for it, but yuck. Any other ideas?
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.
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