I have seperated migrations and module migrations. Now If I want to migrate, I have to use different commands to migrate each of the module. How can I make that all the modules, all the migrations would work with just yii migrate?
Related
I see some issues in my database while updating my model in Django. it only shows 12 fields!
when I added one more field to it and then run makemigrations command, it does not show any changes.
I'm using MySQL database init. is there anything in the Django model like we can only define some fields or we can define as much as we need?
You should be a able to create as my fields as you want. I recommend deleting all files in your migrations folder, except __int__.py file and try python manage.py makemigrations and python manage.py migrate again.
If this doesn't work, also delete the db.sqlite3 file. This usually works for me!
I wrote an application in Yii2, and unfortunately, we've lost all the database back ups. What we now have is the application files only. Is there a shorter way of recreating the 98 database tables based on the existing models?
I notice that some 22 Tables' Schema were cached under "/app/runtime/cache". Has anyone done something like this?
I have to warn that I have used this ones and it's very helpful, when you need some a$$ saving.
This is a very interesting extension for Gii, that will at least help you restart the database, and then you will be working on it to fix some things.
What it will allow you to do, it's to build migrations from the PHPDoc in your models. The use those migrations to rebuild the database.
You need to install https://github.com/Insolita/yii2-migrik by using composer, if it gives you some trouble use version 2.3 and not 3.
Add
"insolita/yii2-migration-generator": "2.3"
Then open Gii and use "Model and PhpDoc migrations".
Now use Yii2 migration system to build the tables, check the migrations, compare them to the models and add relations, them UP them and will need to fix some stuff. It's not perfect. But it saves time.
https://www.yiiframework.com/doc/guide/2.0/en/db-migrations
Good luck.
You need to create migration scripts for each model to do database backup.
You need to create database schema in Migration script up() function and need to use following command to manage database.
- migrate Manages application migrations.
migrate/create Creates a new migration.
migrate/down Downgrades the application by reverting old migrations.
migrate/fresh Truncates the whole database and starts the migration from the beginning.
migrate/history Displays the migration history.
migrate/mark Modifies the migration history to the specified version.
migrate/new Displays the un-applied new migrations.
migrate/redo Redoes the last few migrations.
migrate/to Upgrades or downgrades till the specified version.
migrate/up (default) Upgrades the application by applying new migrations.
For more please refer Official Documentation for Yii2 DB Migrations.
Migration script keeps track of database and if it lost again, you can easily create it.
Thanks.
Can I use MySQL Workbench to create the tables and add data then import / connect that into my Rails app? My Rails app is already connected to MySQL. I am just wondering if I create tables in MySQL Workbench through the app_development schema if that will sync over to my Rails project or not and if there's a way to check to see if it worked?
You can use
rake db:schema:dump
to generate schema.rb from an existing database.
Having schema.rb, you can generate an empty initial migration and put create_table and other statements from generated schema there. Doing this will allow you to use all the relevant rake tasks just as if you developed your database "the Rails way" — via a series of migrations.
I used to utilize
Console/cake schema
in CakePHP 2.
Now I am on my way to CakePHP 3 and find out that Console/cake schema is gone.
So what is the recommended way to manage schema and migrations now?
Lorenzo from the CakePHP core has created the below plugin. It is currently under development and should be considered experimental.
CakePHP 3.0 database migrations plugin
https://github.com/cakephp/migrations
The Migrations Plugin is now part of the CakePHP Core
There are now 2 routes to generate migrations:
Cake (using bake)
bin/cake bake migration [migration_name]
Phinx
bin/cake migrations
Using the Phinx code above it will give you multiple options ie create, migrate, rollback - Create needs a migration name make sure to use CamelCase
I have a django application and until now I used sqLite as database backend. Now when it's quite close to production I thought of moving it all to mySQL which will be used on the box.
I reconfigured my settings to a mysql database and run
manage.py syncdb --migrate
it started creating tables and all but failed in the first (out of 40) migration with an old error (can't insert blob without key length and all that).
I first thought of manually fixing the migration files but quickly realized there is too much manual work.
So I thought ok I'll run manage.py migrate core 0040 (the last migration and that will do the trick) but it still attempts to run the initial one as well:
File "D:\~Sasha\Portman\core\migrations\0001_initial.py", line 23, in forwards
('name', self.gf('django.db.models.fields.TextField')(unique=True)),
... error message
Is there a way to migrate my models somehow without manually fixing the initial migration file and all the other magic?
First, you can't pick and choose migrations to run. migrate core 0040 means run all migrations up to 0040. In other words, it wouldn't run 0041, but it would run 0001-0040.
Now, it's side-stepping your question a bit, but if you have not moved this project to production yet, you don't actually need all those migrations. Assuming they're all schemamigrations you can rollback to zero with:
python manage.py migrate core zero
Then, delete them all (including 0001_initial.py) and simply run again:
python manage.py schemamigration --initial core
To regenerate the initial migration. It will base it off the current state of your models, negating the need for 40 migrations.
It's always a good idea to compress your migrations like this before you move new code to production. Since this is the first launch, you can remove them all and start from scratch, but in future iterations, if you generate 5 migrations during the course of development, before you commit, rollback to before the first of those, then delete those 5 and then generate a new schemamigration. The result is just one migration with all the changes of those 5. Then, you can commit that and migrate in production.
It may not solve your problem completely here, but it will definitely make things simpler to debug.
Very occasionally, I've seen problems with migrations when deploying a project on a mysql backend.
Since you are deploying a fresh copy, you do have a couple options for sidestepping the need to run all of your mightations:
First, if you want to maintain your migration history as-is, you can force syncdb to create all of your tables regardless of migrations, and then run fake migrations to get your new database up to date. That would look like:
python manage.py syncdb --all
python manage.py migrate --fake
Alternatively, if you don't care about your historical migrations, you can clear the old migrations out (just delete them) and then create a new initial migration, like:
python manage.py schemamigration --initial core
Just be sure that you also clear out the south_migrationhistory table in your dev database so that everything stays in sync between dev and prod