I use Rails 2.3 i18n with a database backend plugin :
http://github.com/dylanz/i18n_backend_database
This stores my translations and locales in two DB tables. What would be the best way to get these tables working with my tests? I'm guessing I could write a rake task that would copy the tables from the development DB to the test DB.
Any suggestions?
You could put the data in a seeds.rb file and run that task when loading your test environment. The benefit of this is that you'll also have some way of regaining a basic data structure if you, for some reason, wipe your computer.
One thing you could try is using fixtures for this. Do a google search for db:fixtures:dump or db:fixtures:export_all Rolling own your own implementation should be pretty easy as well.
Related
I am using yaml files to provide initialisation data for the database and also to provide initialisation data for some of my services models. Where should I store these files in a ruby on rails app?
Based on ruby_newbie's comment and the general lack of other responses, it seems that there is no well defined rails way for this. Reasonable locations are
rails_root/data
rails_root/config/data
rails_root/db/data
You should put any data required for your application to run in the seeds file(db/seeds.rb). http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
If you need create a initial database state you can use seeds files in "db/seeds/". After you can use rake to run and create initial state in your database.
In seeds file you can use Rails model without problems and run a follow command rake to create entries.
take db:seed
You can check Rails Documentation:
http://edgeguides.rubyonrails.org/active_record_migrations.html#migrations-and-seed-data
There may be good use case for loading fixed data into a constant without needing to store in a database. Since this is technically fixed "data" I would suggest putting it in
rails_root/db/yaml/
# and you'll have files like
rails_root/db/yaml/measurments.yml
rails_root/db/yaml/locations.yml
# or if you prefer
rails_root/data/yaml/
I am new with Ruby on Rails and have some issues with it. I am writing my application on Rails and i have to install some pre-defined data in my Database to use it in my application. This data is read-only and never change (for example users and roles. There are no use cases to create new users and roles).
So i have to install this data when my application runs first time. I tried to use Migrations to solve this problem, but my manager told me that it is not a right way, cause migrations are usually used to define DB structure changes and not to install any data in DB.
Can you please help me and tell better way to install my pre-defined data using Ruby on Rails?
You'll be able to achieve this using the seeds functionality:
To add initial data after a database is created, Rails has a built-in 'seeds' feature that makes the process quick and easy. This is especially useful when reloading the database frequently in development and test environments. It's easy to get started with this feature: just fill up db/seeds.rb with some Ruby code, and run rake db:seed:
#db/seeds.rb
User.create name: "test", description: "info"
$ rake db:seed
--
If you wanted static data, you'll be able to use a gem such as the config gem -- which gives you the ability to allocate values in config/settings.yml:
This data is then accessible as Settings.company...
You should use seeds. See this rails cast
You could also look at Dibber, that allows you to define your seeds via YML files.
What you are looking to do is seed the database. Rails comes with a db/seeds.rb that you can use to do this. There are also gems such as seed-fu that you could use.
Here is a short tutorial on seeding a database in Rails.
When a rails project grows a lot, you can find yourself having trouble with fixes for the data in the production database.
I have normally used migrations or specific rake tasks for this, but I was wondering if a system similar to migrations existed for keeping the database fixes and run them when needed.
I know you probably figured this out by now but there IS a gem for this... it is called datafix
https://github.com/Casecommons/datafix
basically you create a datafix, like a migration, and a spec for it, then you can run it as needed on the server.
The following gems can be also used for this purpose:
nondestructive_migrations
datafix
migrake
migration-data
data-migrate
I prefer nondestructive_migrations and datafix they are very similar - nondestructive_migrations simpler implementation building on rails migrations.
I have two databases in use in a Ruby on Rails application; one is the database for the application while the second is an independent database over which Rails is not given control.
Problem is when loading fixtures into the dev, it tries to run DELETE statements on the tables in the independent database from the connection to the dev database, which obviously errors out.
I don't want Rails to try to do ANYTHING but read the independent database - I especially don't want it trying to delete tables.
Is there a simple way to tell Rails to ignore the models for the second database when loading fixtures?
UPDATE: To clarify, Rails seems to think the tables from the independent database are part of the development connection, though I have specified the correct connection in the model class using establish_connection. As another note, all model classes work precisely as desired from script/console.
rake db:fixtures:load RAILS_ENV=testing
will do the job for database configured as testing in your database.yml
I think you might also be able to accomplish this by adding all the tables in the independent database to ActiveRecord::SchemaDumper.ignore_tables in environment.rb, like so:
ActiveRecord::SchemaDumper.ignore_tables = ['independent_db_table1', 'independent_db_table2']
Okay...my issue was that I used the script/generate to create the models from the secondary database, which also created fixture, schema, test, and migrations files. I had removed the schema, test, and migrations files, but did not remove the generated fixtures (they were empty files) as I did not think it had created any.
After removing all files (including the models) from the secondary database and re-running the migrations for the dev db, I added back only the model files and the database in databases.yml from the secondary db, which solved the issue.
I still can't explain why Rails' rake tasks were looking in the wrong database and I am a little disappointed with rails' addition of the schema_migrations table in the secondary database, which it obviously does not need.
However, it works now.
Delete the model_name.yml file in your test/fixtures directory and Rails will not try to delete these tables.
Better yet, delete all your *.yml files and stop using fixtures entirely.
I have a rails application where each user has a separate database. (taking Joel Spolsky's advice on this). I want to run DB migrations from the rails application to create a new database and tables for this user.
What is the easiest way to do this?
Maybe the db migration is not the best for this type of thing. Thanks!
It would be nice if it could be a completely automated process. The following process would be ideal.
A user signs up on our site to use this web app
Migrations are run to create this users database and get tables setup correctly
Is there a way of calling a rake task from a ruby application?
To answer part of your question, here's how you'd run a rake task from inside Rails code:
require 'rake'
load 'path/to/task.rake'
Rake::Task['foo:bar:baz'].invoke
Mind you, I have no idea how (or why) you could have one database per user.
We use seperate configuration files for each user. So in the config/ dir we would have roo.database.yml which would connect to my personal database, and I would copy that over the database.yml file that is used by rails.
We were thinking of expanding the rails Rakefile so we could specify the developer as a environment variable, which would then select a specfic datbase configuration, allowing us to only have one database.yml file. We haven't done this though as the above method works well enough.
Actually I have discovered a good way to run DB migrations from an application:
ActiveRecord::Migrator.migrate("db/migrate/")