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.
Related
I started my project with sequeliz-cli by running init command.
but i deleted the migrations and seeder folder. and started creating the models.
i need to first create a db in workbench, and then ran db.sync() from sequelize, which created the tables in db. Its running kind of fine.
can we complete the whole project without using migrate and deploy it on production env, will not using migrate disadvantageous??
Migrations help you to use different versions of your app and DB in different production environments and change your DB structure as long as to add some initial data precisely.
sync method would be dangerous in such scenarios with different versions in a situation when you run a newer version of your app on an older DB occasionally.
If you have a simple DB structure that won't change or will be the same on all prods then you can use sync.
How to upgrade a production DB schema from a dev DB schema automatically, via command line? The dev version has changes to the schema that need to be made in the production schema, but I cannot lose the data in production.
Schema Migrations
Most modern projects use a tool to track each individual change to the database, and associate some version number with the change. The database must also have some table to store its current version. That way the tool can query the current version and figure out which (if any) changes to apply.
There are several free tools to do this, like:
Liquibase
Flyway
Rails Migrations
Doctrine Migrations
SQLAlchemy Migrate
All of these require that you write meticulous code files for each change as you develop. It would be hard to reverse-engineer a project if you haven't been following the process of creating schema change code all along.
There are tools like mysqldbcompare that can help you generate the minimal ALTER TABLE statements to upgrade your production database.
There is also a newer free tool called Shift (I work with the engineer who created it), which helps to automate the process of upgrading your database. It even provides a nice web interface for entering your schema changes, running them as online changes, and monitoring their progress. But it requires quite a lot of experience to use this tool, I wouldn't recommend it for a beginner.
You can also use MySQL WorkBench: https://dev.mysql.com/downloads/workbench/
if you want an easy GUI, and cross OS compatible ;)
I wanted to create a auto-generated script of database with sql extension using git. I know it is stupid question, but how comfortable would it be, when I know starter developers are also working at the same database and I can give them freedom to use live database as per their own without loosing my important data and chance to revert at live.
The main concern is it must be using GIT. My one command and creation of script become ready.
Any suggestion will be helpful. Thanks in advance.
Here are some suggestions that can help with database management in a multi-developer, version-controlled environment.
Use a migrations library. There might be one for your stack (e.g. South if you're working with Django 1.6 or earlier, Doctrine Migrations for Doctrine, Active Record Migrations for Rails) or you could use a general purpose tool like Liquibase.
In general, when working with database migrations libraries you end up with a number of versioned files that modify your database in some way. For example you might have a migrations directory containing
0001_create_initial_schema.sql
0002_add_user_model.sql
0003_replace_plaintext_passwords_with_hashed_passwords.sql
Depending on your library, these scripts may logically be written at the database level or at the ORM level. In general, each script is reversible.
This lets developers easily upgrade their database schemas as development continues.
Set each developer up with their own copy of the database. You could ask them to install MySQL locally and have initialization instructions along the lines of "create database, create user, add credentials to config file, run migrations".
Alternatively you could use something like Vagrant to easily create self-contained virtual machines for developers to use. Vagrant can easily install MySQL and create a database.
Finally, you could create databases for your developers on a centralized server, e.g. app1_john, app1_cindy, app1_joel.
Using these guidelines, developers have the flexibility to modify their own databases as needed. They can share these modifications cleanly by adding migrations to the code repository. Any developer can reset their database at any time, either by running all the migrations in reverse or by simply dropping the database.
Using this model there should be no need for most developers to have administrative access to the production database. Only allow trusted users to modify the production database, and always upgrade your database schema using the well-tested migrations scripts that you have used everywhere else.
And, of course, keep regular backups.
So my Mac went down and now trying to build my project on my new Mac. I need to know when running rake db:migrate does it look at the schema.rb file?
As I am getting
Mysql::Error: Table 'myproject_development.users' doesn't exist: SHOW FIELDS FROM `users`
Even when I run rake db:migrate:up VERSION=001 which has no reference to users I get the same error?
If it matters my migrations start like
001_...
002_...
003_...
20100222171241_...
The migration code generally doesn't look at the schema file. It looks at the names of all the migration files and the database table called schema_migrations, and determines which migrations haven't been run yet. (I believe it does dump the schema at the end of running migrations.) Either your missing a migration, or your schema_migrations table is out of sync with your database.
After making a backup, you can start to troubleshoot. Do you have a migration that creates the users table? If not, where did it go? If you have it, why isn't it running?
FYI The migrations that start with numbers (eg. 001) are older versions of migrations. Sometime around 2.2 or 2.3 the names of the migrations were changed to dates, which is what you are seeing in the later migrations.
There may be a problem with the way those first few migrations are named, and they are not being found (I can't remember the migration story when this naming scheme switched). And maybe it tracked the migrations differently back then so there may be some futzing to make it work with the more modern scheme. You can fairly safely rename them following the new scheme, using the datestamp of the file.
Hope this helps.
Is there any plugin that directly exports MYSQL Workbench data model directly to YML for Propel consumption?
Yes, MySQL Workbench Plugins are available for generating schemas for Propel, Doctrine, Symfony, etc
http://forums.mysql.com/read.php?153,208229
Just an update on this issue. If you are looking for a quick and convenient way to export your database tables to entities and mapping .yml files, there used to be a plugin for Workbench that would do this, but this LUA is not supported any more, unfortunately. It worked great -- too bad because if you use MySQL Workbench, a plugin would ideally be the most convenient and fastest way to export your database as entities into your Symfony project.
So, the next best solution I found is installing a utility that can be executed from Symfony's app/console called "mysqlworkbenchschemaexporter". With this utility, you will have to save your Workbench files (*.wmb) then upload them to a folder, then the following app/console commands are available:
app/console mysqlworkbenchschemaexporter:dump
app/console mysqlworkbenchschemaexporter:withRepository
Without buying an ORM tool like Skipper, which costs over $300, I did find this recently updated solution that is supported at:
https://github.com/turnaev/mysql-workbench-schema-exporter-symfony2-bundle
I hope this helps other Symfony developers save some time with entity creation and ORM mappings!
When using symfony 1.x, personally I prefer the following process:
design the model with workbench
use the "synchronize model" option to apply changes to the DB
run the propel:build-schema task to update the schema.yml
run the propel:build --all-classes task (it implies model, forms and filters)
Please note: step 3 will overwrite your entire schema.yml file. If you need to add special tweaks to it, just add a schema.custom.yml to your project and you're good to go.
If export from MySQL workbench isn't sufficient, you can try our tool Skipper - formerly ORM Designer (I'm chief developer). With Skipper you can define and export also behaviours, Propel specific column/table/... attributes and much more.
http://www.skipper18.com