database-migration

In order to doing migration in Yii I used this lines <?php class m110714_122129_users extends CDbMigration { public function up() { $this-> createTable('{{users}}',array( 'id' => 'pk', 'username' => 'VARCHAR (80) NOT NULL', 'password' => 'VARCHAR (80) NOT NULL', 'email' => 'VARCHAR (128) NOT NULL', 'activekey' => 'VARCHAR (128) NOT NULL DEFAULT \'\'', 'createtime' => 'INTEGER (10) NOT NULL DEFAULT \'0\' ', 'lastvisit' => 'INTEGER (10) NOT NULL DEFAULT \'0\' ', 'superuser' => 'INTEGER (1) NOT NULL DEFAULT \'0\' ', 'status'=> 'INTEGER (1) NOT NULL DEFAULT \'0\' ', )); } public function down() {

I've run artisan migrate:reset . I've deleted some of my migration files because I didn't need these tables anymore. I ran composer dump-autoload followed by artisan dump-autoload I ran artisan migrate and I keep getting this error: PHP Fatal error: Class 'Foo' not found in /vagrant/LaravelBackend/vendor/laravel/framework/src/Illuminate/Database/Migrations/Migrator.php on line 297 I tried to: Run again composer dump-autoload and artisan dump-autoload (also used artisan clear-compiled ) Remove the migration table and run artisan migrate:install Remove the vendor and composer.lock file and run

Closed . This question needs to be more focused. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it focuses on one problem only by editing this post . I've looked at both Liquibase and Flyway individually and on an individual comparison alone, Liquibase seems like the better tool for our needs. Some sources mention using both Liquibase and Flyway together. Liquibase seems to have everything Flyway has and more flexibility when it comes to rollbacks. The main advantage of just Flyway seems to be not having to use XML, but Liquibase

In Rails 4.2, when creating a table or adding a reference via references or add_reference how do you specify that the foreign key should cascade on delete. Command to generate scaffold: rails g scaffold Child parent:references name:string Resulting migration: create_table :childs do |t| t.references :parent, index: true, foreign_key: true t.string :name t.timestamps null: false end This should work create_table :childs do |t| t.references :parent, index: true, foreign_key: {on_delete: :cascade} t.string :name t.timestamps null: false end According to ActiveRecord::ConnectionAdapters:

I have a table in a Rails application which (in schema.rb) looks like: create_table "users", :force => true do |t| t.string "name", :null=>false t.string "address", :null=>false end I would like to write a rails migration to allow nulls for the address field. i.e. after the migration the table looks like this: create_table "users", :force => true do |t| t.string "name", :null=>false t.string "address" end What do I need to do to remove the constraint? Not sure you can call t.address ? Anyway... I would use change_column like so change_column :users, :address, :string, :null => true Docs...

Can someone give me a short introduction to doing DB migrations in Rails using Mongoid? I'm particularly interested in lazy per document migrations. By this, I mean that whenever you read a document from the database, you migrate it to its latest version and save it again. Has anyone done this sort of thing before? I've come across mongoid_rails_migrations , but it doesn't provide any sort of documentation, and although it looks like it does this, I'm not really sure how to use it. I should point out I'm only conceptually familiar with ActiveRecord migrations. If you want to do the entire