I am trying to use a secondary database connection for some of my migrations in the following way:
# app/models/staging/migration.rb
class Staging::Migration < ActiveRecord::Migration
def self.connection
ActiveRecord::Base.establish_connection(:staging_db).connection
end
end
# db/migrate/<timestamp>_create_foo.rb
class CreateFoo < Staging::Migration
....
end
In my database.yml the staging_db connection is configured.
When I run rake db:migrate, the table foo is created correctly in the staging_db schema, and the table schema_migrations is created in the RAILS_ENV=development connection. However db:migrate reports the following error (which fails subsequent migrations):
Table 'staging_db.schema_migrations'
doesn't exist
Is there a way to tell Staging::Migration to look for the schema_migrations table in the current RAILS_ENV connection?
BTW, I am aware of the fact that staging_db is then not RAILS_ENV-aware. This is fine for me since every server has its environment configured through a separate database.yml which is not in my repo.
You should try do this before your first migration in the staging_db:
ActiveRecord::Base.connection.initialize_schema_migrations_table
This will create a schema migration table in the staging db. If this is not what you want you will have to manipulate some other things. The schema_migrations_table_name determines which table contains the migration versions:
def schema_migrations_table_name
Base.table_name_prefix + 'schema_migrations' + Base.table_name_suffix
end
So if you have a table_name_prefix defined it will cause the schema_migration_table to look in the staging db.
I already did this but outside of rails, it should not be very different in rails, here is how I do it:
The first thing is to connect your database before your migrations are executed, in rails the best place may be in an initializer:
MyModel.establish_connection({
:adapter => "mysql2",
:database => "mydb",
:username => "root",
:encoding => 'utf8'
})
The hash will be usually loaded from an yml file but this is the result you want in the end.
MyModel can be an abstract class if you have multiple models in this database.
Next in your migration when you want to migrate this database you just have to do this:
class DoDomething < ActiveRecord::Migration
def self.connection
MyModel.connection
end
def self.up
add_column [...]
end
end
One thing to note when doing things this way is that there will be only one schema_migrations table and it will be in the "main" database.
Related
I had to put execute into one table migration. It looks like this:
class CreateFoos < ActiveRecord::Migration
def up
create_table :items do |t|
t.integer :bar
end
execute("GRANT SELECT ON items TO otheruser;")
end
def down
drop_table :items
end
end
This works well, but db/schema.rb file, which should be authority for database creation, is missing that line with execute command.
Is there something I'm missing or this is default behavior when schema.rb is generated?
I can bypass this issue by simply ignoring schema.rb and generating tables with rake db:migrate when deploying, but I saw recommendations to avoid doing so.
Any ideas?
Active Record's schema dumper can't handle database specific items like foreign keys, constraints, grant statements, etc. Change your database format to sql instead of of ruby. In your application.rb file:
config.active_record.schema_format = :sql
This will use a database specific tool to dump the schema to db/structure.sql. For example, if you are using PostgreSQL it will use pg_dump to dump the schema. The drawback to using the sql format is that the dump is no longer database agnostic. If you were to migrate from PostgreSQL to MySQL you would not be able to use the generated structure file to create a new database.
You can also generate a sql dump with the rake command:
rake db:structure:dump
I have a Rails 4 application that uses two MySQL databases (primary, secondary). Both databases are configured for development, production and test environments in the database.yml file:
development:
...
database: primary
...
production:
...
database: primary
...
test:
...
database: primary
...
secondary_development:
...
database: secondary
...
secondary_production:
...
database: secondary
...
secondary_test:
...
database: secondary
...
For now I only have one model that is stored in the secondary db. Below is the migration code that creates a table for this model:
class CreateTags < ActiveRecord::Migration
ActiveRecord::Base.establish_connection "secondary_#{Rails.env}"
def change
create_table :tags do |t|
t.string :name
t.integer :account_id
t.timestamps
end
end
end
When I run rake db:migrate, the table is correctly created in the secondary database. But when I run rake db:migrate a second time, it shows me an error table already exists, which I think related to the fact that rake task adds migration version to versions table of primary database. I am ignoring this for now.
But, when I run some unit test using rake test TEST=test/path_to_test_file.rb, it shows me an error saying Tags table does not exist in the secondary DB. I've checked the logs and found that Tags table is created, BUT in PRIMARY database which is wrong.
So, in short, how to change the migration code to make sure that Tags table will always be created in the secondary DB?
I have tried:
https://stackoverflow.com/a/11020572
https://stackoverflow.com/a/9652660
But it is not working for me :(
UPDATE 1:
Based on #User089247 suggestion, I have tried to run RAILS_ENV=test rake db:create and RAILS_ENV=test rake db:migrate. It says that my primary database is already created which is true, but it says nothing about my secondary databse because secondary DB has separate configuraion secondary_test. Based on my understanding, it should be possible to create custom rake task (or override existing one) but then this taks should be used by rake test. Is it possible ? Or am I missing somethings ?
What you want to do here is specify the usage of the secondary database on the model, not just in the migration:
class Tag < ActiveRecord::Base
establish_connection "secondary_#{Rails.env}"
end
This blog post has some helpful additional info if you are going to be using the secondary database for multiple models: http://pragdave.me/blog/2006/01/03/sharing-external-activerecord-connections/
I'm having trouble creating models in my RoR application for preexisting tables in my sql server database.
In ruby console when I type: ActiveRecord::Base.connection.tables, the following is returned:
["Bank", "Owner", "Location", "Zone"].
The above is returned without any models or migrations having been created in the app. So the next step is to create a model...
rails g model Bank
And edit the model:
class Bank < ActiveRecord::Base
set_table_name = "Bank"
set_primary_key "BankID"
end
And edit the migration:
class CreateBanks < ActiveRecord::Migration
def change
create_table "Master.Bank" do |t| // Because Bank is in the 'Master' schema, not the default 'dbo'
t.timestamps
end
end
end
The edits to the model and migration file I have come to understand from my own research should allow me to successfully link a model in my app to a legacy database with table names that do not match Rails' conventions and in the appropriate schema.
However, after doing all this, the command rake db:migrate generates the error, "TinyTds::Error: There is already an object named 'Bank' in the database."
What am I doing wrong?
As you are creating from a legacy DB, you don't know the migrations, as the tables already exist. Rails should introspect the table and generate the correct fields. Just make sure that the default schema for the user you are accessing the database with is the schema that owns the tables.
I have some data that needs to be edited online (ie cannot be a seed), but that also needs to be the same in all environments. So far the only thing i found is the has_alter_ego gem, but it does not seem to be supported anymore.
Example:
I make many changes to the default_settings table in my development database
I would like to keep only these changes transferred from my development to production database (and not the other tables which have test data)
I would rather not use a seed unless there is a way to edit seeds from the web
One option that i'm considering is having a separate database.
Anyone have a clean solution to this problem? Thanks!
How about you define a second sqlite3 database which gets checked in with your app for just this table, and use it for all three environments? For example, the sqlite3 file could be named other_db.sqlite3:
config/database.yml:
... (your other settings for dev, test, and prod databases)
other_db:
database: db/other_db.sqlite3
adapter: sqlite3
timeout: 5000
app/models/external.rb:
class External < ActiveRecord::Base
self.abstract_class = true
establish_connection :other_db
end
app/models/cross_environment_data.rb
class CrossEnvironmentData < External
...
end
In this case (though thoroughly discouraged), I would put it in a migration.
/db/migrate/_edit_data.rb
class EditData < ActiveRecord::Migration
def self.up
<Do your edits here>
end
def self.down
<undo edits here>
end
end
Then:
rake db:migrate
Now you have the same data across all environments.
For example if you wanted to append some text to the end of a chunk of text across all records of a Post.text.
script/generate migration append_text
/db/migrate/_append_text.rb
class AppendText < ActiveRecord::Migration
def self.up
Post.each{ |p| p.update_attribute(:text, "#{p.text} my additional text")}
end
def self.down
raise ActiveRecord::IrreversibleMigration
end
end
When you run:
rake db:migrate
on development, the changes will propagate accordingly and when you deploy to your other environments, you will have to run the same command and they will receive the same changes. This is more of an irreversible migration because you won't be able to validate that the data did not change since the time of migration, so make sure this is what you want to do (run it on dev) =)
NEW SOLUTION:
https://github.com/ricardochimal/taps
when you want to transfer a list of tables
$ taps push postgres://dbuser:dbpassword#localhost/dbname http://httpuser:httppassword#example.com:5000 --tables logs,tags
I'd like to know which is the preferred way to add records to a database table in a Rails Migration. I've read on Ola Bini's book (Jruby on Rails) that he does something like this:
class CreateProductCategories < ActiveRecord::Migration
#defines the AR class
class ProductType < ActiveRecord::Base; end
def self.up
#CREATE THE TABLES...
load_data
end
def self.load_data
#Use AR object to create default data
ProductType.create(:name => "type")
end
end
This is nice and clean but for some reason, doesn't work on the lasts versions of rails...
The question is, how do you populate the database with default data (like users or something)?
Thanks!
The Rails API documentation for migrations shows a simpler way to achieve this.
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
class CreateProductCategories < ActiveRecord::Migration
def self.up
create_table "product_categories" do |t|
t.string name
# etc.
end
# Now populate the category list with default data
ProductCategory.create :name => 'Books', ...
ProductCategory.create :name => 'Games', ... # Etc.
# The "down" method takes care of the data because it
# drops the whole table.
end
def self.down
drop_table "product_categories"
end
end
Tested on Rails 2.3.0, but this should work for many earlier versions too.
You could use fixtures for that. It means having a yaml file somewhere with the data you want to insert.
Here is a changeset I committed for this in one of my app:
db/migrate/004_load_profiles.rb
require 'active_record/fixtures'
class LoadProfiles < ActiveRecord::Migration
def self.up
down()
directory = File.join(File.dirname(__FILE__), "init_data")
Fixtures.create_fixtures(directory, "profiles")
end
def self.down
Profile.delete_all
end
end
db/migrate/init_data/profiles.yaml
admin:
name: Admin
value: 1
normal:
name: Normal user
value: 2
You could also define in your seeds.rb file, for instance:
Grid.create :ref_code => 'one' , :name => 'Grade Única'
and after run:
rake db:seed
your migrations have access to all your models, so you shouldn't be creating a class inside the migration.
I am using the latest rails, and I can confirm that the example you posted definitely OUGHT to work.
However, migrations are a special beast. As long as you are clear, I don't see anything wrong with an ActiveRecord::Base.connection.execute("INSERT INTO product_types (name) VALUES ('type1'), ('type2')").
The advantage to this is, you can easily generate it by using some kind of GUI or web front-end to populate your starting data, and then doing a mysqldump -uroot database_name.product_types.
Whatever makes things easiest for the kind of person who's going to be executing your migrations and maintaining the product.
You should really not use
ProductType.create
in your migrations.
I have done similar but in the long run they are not guaranteed to work.
When you run the migration the model class you are using is the one at the time you run the migration, not the one at the time you created the migration. You will have to be sure you never change your model in such a way to stop you migration from running.
You are much better off running SQL for example:
[{name: 'Type', ..}, .. ].each do |type|
execute("INSERT INTO product_types (name) VALUES ('#{type[:name]} .. )
end