I'm learning Ruby on Rails and it talk about how Migration changes the state of the database by using the command bundle exec rake db:migrate, but what exactly does that mean?
Migrations are a way of defining the schema of your database. Rails provides an API for adding/dropping/modifying database columns and tables using Ruby code. These files are knows as migrations. Here is a link to the documentation: http://edgeguides.rubyonrails.org/active_record_migrations.html,
but migrations are not a concept unique to Rails. For example, Django also uses migrations to manage the state of the database. The short answer is that migrations are a code-based way to manage the structure, or schema of your database.
It executes all the migrations that you created/generated via rails generate migration X.
Basically migrations are scripts that deal directly with the database (creating tables, fields, indexes). Hope that helps! :)
Related
I am trying to build a read-only Rails API that uses another Rails application's DB as its database.
So far I configured the read-only API's database.yml to point to the existing databases, generated models via rails g model but did not run the migration since I already have the corresponding tables in the existing databases.
I wanted to follow TDD approach and started to write tests but my problem is I cannot create instances of models since I did not create the table for that model.
Example Case
I generated a model named project which exists as a table in the existing DB that I am going to use to read data, but since I did not run the migration for that model it does not exist in the current API's DB.
So, I just dumped the schema.rb from the existing DB, copied it as my read-only API's db/schema.rb and run rake db:schema:load when RAILS_ENV=test.
I wonder if there's a better way to do this? Is my way of writing a read-only API like this is correct? I am open to any suggestions for this topic.
Cheers.
Is is correct to assume that migrations in ruby on rails are simply updates to any database. And that the rake db:migrate script only serves to actualize these changes?
Yes.
Migrations are a convenient way for you to alter your database in a
structured and organized manner. You could edit fragments of SQL by
hand but you would then be responsible for telling other developers
that they need to go and run them. You’d also have to keep track of
which changes need to be run against the production machines next time
you deploy.
Active Record tracks which migrations have already been run so all you
have to do is update your source and run rake db:migrate. Active
Record will work out which migrations should be run. It will also
update your db/schema.rb file to match the structure of your database.
Migrations also allow you to describe these transformations using
Ruby. The great thing about this is that (like most of Active Record’s
functionality) it is database independent: you don’t need to worry
about the precise syntax of CREATE TABLE any more than you worry about
variations on SELECT * (you can drop down to raw SQL for database
specific features). For example you could use SQLite3 in development,
but MySQL in production.
Source: Ruby on Rails Guides: Migrations
I am presently designing a database schema for use in a Rails 3.1 application.
At the moment, I am using MySQL Workbench to design the schema visually, and then manually translating this to Rails migrations & models.
Can anyone indicate if there are any solutions that will allow a schema to be designed visually and translated automatically (i.e. via script) to Rails?
Thanks!
First off, the "database-first" approach definitely isn't really the preferred way to work with Rails... but if you really want to...
If you generate the the tables from your schema you can configure the Rails app's config/database.yml file to connect to your database, then call rake db:schema:dump which generates the db/schema.rb file from the database. Then you can create a migration and copy the code from db/schema.rb into the change (or self.up) method.
Note that this does not automatically create model classes - you'll have to create these yourself, remembering to --skip migration in the rails generate model, and possibly needing to make liberal use of the set_table_name (to map the model class to the right table name), alias_attribute (to map model attributes to the right columns), and perhaps set_primary_key.
There were some more complete approaches to this sort of thing for older versions of Rails (Magic Model Generator and reverse_scaffold are two that I've found), but I don't know of any that have been upgraded to work with Rails 3.
SQL Editor is a Mac application that allows you to visually design a DB schema and then export it as something you can easily import as a schema in Rails.
You will still have to create the models yourself.
For rails existing applications or the new application, you can use this for db design
https://dbdiagram.io/
I use railshelper.com which helps me in a simplistic manner to generate quickly some common rails cli commands !
I think Mogwai ERD will help you out, there you can design your ERD and convert it in to a DB schema.
And I think there is no software for design Rails schema, it's just that you make your schema adhere to Rails conventions. But of course Rails can be configured to almost any schema.
Does anyone know of any specific DSL implementations used to import legacy Oracle database schemas. I have tried to just run db:schema:dump on my existing db I want to port to a new ruby app. However, the rake dies about halfway through with out any error. It kinda just locks up. I started looking for the best way to tackle this and found examples of how to override some stuff for SQLServer but not much for Oracle.
I basically want to pull in the schema and generate a scaffold and model from it.
Is there a more simple way to do this or will I have to invent the wheel?
The firs question - are you using original ActiveRecord Oracle adapter or oracle_enhanced adapter (http://github.com/rsim/oracle-enhanced)? I recommend to use oracle_enhanced adapter as I made there some performance improvements for schema dump.
Rails provides two ways for schema dump:
rake db:schema:dump
This will create schema.rb file with Rails migrations for schema creation. In Oracle case it will search for all tables in user local schema (user is specified in database.yml) and will try to translate Oracle data types to Rails model attribute types. If you have some data types which are not supported by Rails then you might loose them. But if you want to reengineer your application in Rails way then this is preferred approach. As I said I made some performance improvement in oracle_enhanced adapter for schema dump in case of large Oracle data disctionaries (if you have thousands of tables in all schemas).
rake db:structure:dump
This will create SQL schema file (e.g. db/development_structure.sql) which you can execute in other Oracle database (this will not work on other databases). This might be faster way to create schema dump and it will not lose Oracle specific data types. But in this way you can get into trouble later when you will use ActiveRecord with this database and then will notice that some data types are not processed correctly. Therefore I recommend to use Rails migration to maintain schema and not raw SQL.
But if you want to use Rails with some existing Oracle database then you don't need to recreate this schema - you can just point database.yml to this existing database schema and start to create ActiveRecord models on top of existing tables. See http://blog.rayapps.com/2008/09/26/openworld-unconference-presentation-about-rails-on-oracle/ for some tips how to use Rails with legacy Oracle databases.
did you try rake --trace?
By the way Oracle legacy schemas is a small cottage industry.
http://github.com/rsim/legacy_oracle_sample.git/README.txt
http://blog.rayapps.com/2008/06/28/activerecord-oracle-enhanced-adapter-version-111-released/
http://www.oracle.com/technology/pub/articles/saternos-rails.html
http://redsquirrel.com/cgi-bin/dave/dynamic/rails.multiple.oracle.dbs.html
update: this only fail if you use ", :require => false". Removing this param, work as expected.
This really should work?
~/Projects/test (master) $ rake db:structure:dump
(in /Users/plentz/Projects/test)
rake aborted!
Task not supported by 'oracle_enhanced'
(See full trace by running task with --trace)
Gemfile
gem 'activerecord-oracle_enhanced-adapter', :require => false
Using activerecord-oracle_enhanced-adapter (1.3.2)
So what's the best way to create new tables in a Sqlite database in Rails 2. I have created the database using rake db:migrate command. So should I write individual sql scripts to create a database or use rake somehow. I don't need scaffolding.
Basically use migrations.
Some useful help on how to use migrations is available at http://wiki.rubyonrails.org/rails/pages/understandingmigrations and http://wiki.rubyonrails.org/rails/pages/UsingMigrations. A good cheatsheet that I use is also available at http://dizzy.co.uk/ruby_on_rails/cheatsheets/rails-migrations.
Basically migrations use ruby code to create your database tables for you. It is far easier (in my opinion at least) to use nice ruby code to do this rather than SQL DDL - it also does various things automatically for you (like adding id fields to all your tables as rails requires). You can then use rake tasks to actually apply the migrations to your database. The other major advantage that migrations give you is that they are reverseable - so your database is versioned and you can easily jump from one version to another.
Try to avoid writing CREATE/ALTER table scripts and use ActiveRecord migrations instead. A few reasons spring to mind:
Portability: it's much easier to let
AR deal with cross-platform flavour
differences
Change control: your
migrations can manage changes in
both directions with the VERSION=
option, something that's not easy to
do with SQL
It's the Rails way:
follow the Rails conventions unless
you have a compelling reason not to
do so
Simplicity: you don't have to worry about id and timestamp columns when you use migrations, which saves you having to remember them if you work in SQL
If you are not using scaffolding then you should use script/generate migration to create a migration file for each table. There is no need to use sql scripts. After creating some migrations you can apply them to your database using rake db:migrate.