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/")
Related
I have a rails app that only allows users to search and view the contents of its (MySQL) database. To add records to the database, I'd like to run a ruby script automatically twice a day which generates the contents of the database and then updates the db. Is this possible, or does my script have to be a part of the rails web app?
Just to lead you in the right direction - you can use a Rake task for this. These are usually put in the lib/tasks directory.
It's a good idea to separate non-web related things such as seeding or updating a database. If this is a scheduled job, you can use whenever to hook the rake task to cron.
Solved this using rails runner command
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.
I have a simple Rails app which populates into a certain database and there are few migration scripts. I would like to create a different set of model classes and actually migrate the schema pertaining to those files into a different database. How should we do that? Will I be able to do this from the same rails app?
Well, change the database name in database.yml , then follow the usual steps,
bundle exec rake db:setup should do the work.
Or you could create a seperate database_2.yml and then make a database.rake file and follow the steps here
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.
This is probably a stupidly easy question for a Rails person but is causing me no end of confusion. I downloaded several open source Rails projects but am not able to run them. Usually, are you supposed to do a db:migrate before you try to run a Rails project? I thought they were supposed to just run.
I guess it depends on how the database is configured. If it's pointing to a sqlite db, then its probably all ready to go, otherwise if its a full blown RDBMS, then yes the database would need to be migrated assuming of course that the settings in database.yml are configured correctly.