I want to run two rails websites (homepage and app) on the same database. However, migrations dont work because both websites try to use schema_migrations table at the same time.
Is it possible to override default schema_migrations table name? Any other ideas how to solve this problem?
The schema_migrations table name is kept in ActiveRecord::Migrator.schema_migrations_table_name, which you might me able to override (in environment.rb, initializers, etc.), but I haven't tried this.
On the other hand, if you use unique migration IDs in both application (default in 2.1 onwards, I think), migrations from two applications should work with a single schema_migrations table.
See this screencast for more information on how migrations work in Rails 2.1 and up.
I don't know when this was added but Rails 4 seems to support it now.
From the Rails documentation
config.active_record.schema_migrations_table_name lets you set a string to be used as the name of the schema migrations table.
If you are using a version of Rails where this is not supported then an alternative could be to use table_name_prefix. If you are using this approach, I'd make sure that your version of Rails prefixes schema migrations with table_name_prefix by looking at the source code.
Related
I’m trying to add a string column to a SQLite 3 database in rails. Use the normal syntax "rails generate migration AddAuthorColumnToPublications author:string". I run the migration, it works without errors.
I change the attributes accessor in the Publications model to include the Author column. I check in the schema, the new column has been included in the schema.
I go to my database and the new column does not appear in the index of the Publications table. I’ve tried including it specifically in the index, but to no avail.
The only thing I can think of here is that because I am using Ubuntu, the syntax may be slightly different (as it has been for certain things).
I have looked in books and on the internet, and the syntax seems correct (can also use underscores as well as camel casing to name the migration), but I can’t find anything specific to Ubuntu on this particular issue.
I would appreciate any and all help on this matter.
Run this command:
rake db:migrate
Migrations are not run automatically. You need to run rake db:migrate in order to run all the migrations and update the database.
Also, review your database.yml file and make sure that you're using the sqlite database that you're opening. The syntax of the command is not different.
Is it possible to use Rails to auto-generate a migration based on changes that took place in the database outside of Rails since the last migration?
I know that running db:migrate will change the schema.rb to match what's in the database.... (at least if don't make any migrations but I do change the database in some way manually). What I'm wondering is, if there is a way as part of that same mechanism or process to have it create a migration out of those changes.
Many thanks!
I don't think this is something Rails would do or is trying to solve. Rails wants you to explicitly manage those changes through migrations so that your database is under control (and source control).
See if this gem is what you want. - https://github.com/pjhyett/auto_migrations
It might not work with Rails 3. I think since you edit your DB directly you'd have to run rake db:schema:dump to update the schema.rb file.
If you want to capture the deltas between the different db change points then see this SO answer:
How to generate Rails Migration class automatically from MYSQL database instance? , just repeat his steps along the way.
I'm using NetBeans + Rails 2.3.8.
I notice that whenever I generate a model, the migration filename for it includes the date and time:
Model Name: User
Migration File Name : 20100916172053_create_users.rb
But when I see books (like Agile Web Development with Rails), the (rake-generated examples int it) all show simple numbers like 001_create_users, 002_create_sessions etc.
How do I get that simple numbering scheme (it looks neater, easier on the eyes when searching for a model)?
Or is it better to just go with the flow and not bother about what kind of versioning number is used?
You can add this to config/environment.rb
config.active_record.timestamped_migrations = false
Note that the default was changed to timestamps because it (the numbering version) causes problems in multi-developer environments. When two developers both create a migration between source control updates, the migrations will have the same numbers. If you are working alone that would not be a problem.
Also, I'm not sure how it will work if you already have existing migrations, so be careful if that is the case.
The migrations wth the timestamp are the newer form as that allows more than one person at a time to add a migration to the project. This is particularily useful in projects with more than one developer as with the old numbered approach you would need to add the migrations in lock step or renumber them.
So I would recommend that you stick with the timestamp form.
However if you still want to use the older numbered forms you can do as #ngoozeff suggested and add:
config.active_record.timestamped_migrations = false
to either your environment.rb or an initializer.
When I manually enter tables into the .rb file in the migrate folder nothing shows up. I have followed a few different "how to's" but I can't get the tables to show up when I preview my work. I can however get one table to show up if I create it in the parameters when generating a scaffold, but that's one table. I have Rails version 2.3.4 and version 1.2.3 installed on my lame Windows Vista. I have tried using both versions multiple times. I am also trying to follow the Ruby on Rails for Dummies book, but it seems a little outdated. Any tips on getting tables to work? Its supposed to be really simple and take "just minutes" to complete this simple app. Maybe something didn't install right? Maybe a better book?
Just want to make sure you're using all the tools available to you:
To generate a migration file:
./script/generate MigrationFileName
Take a look at the Database Migrations Guide from the official Rails Guides for the correct syntax and options for creating a migration file.
Once you've created your migration, you need to run the following:
rake db:migrate
This will populate the database with the information specified in the migration file.
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.