Rails app:

Db folder: everything related to the database goes here, migrations go here too.

To generate a new migration from the command line:

rails generate migration MyMigrationNameHere

This will create a folder migrate (if it does not already exist) in the db folder and inside it it will put a file with name
in the format:
timestampValueHere_my_migration_name_here.rb

The timestamp will be used as an id for each migration!

2)

To generate a model from cmd:

rails generate model User

this will create many files, the models/user.rb model file, 2 test files test/models/user_test.rb and
test/fixtures/users.yml, AND a migration file db/migrate/timestamp_create_users.rb which contains the db
migration for adding the user table in the database!

3)

In a migration file, to create a new table the code is like:

def up

create_table :users #if we dont want default id column: :users, {:id => false}# do |t|

#maybe the db (mySql or postgres support varchar field, nota string field. #Rails handles this for us
and we dont have to do anything related to a #specific database format. So, this code can be used
in th future even if we #change the database from mysql to postgres for example!
t.column first_name, :string, :limit => 25

#OR
t.string last_name, :limit => 50 # OPTIONS HERE
#other TYPES for table columns in rails:
#binary
#boolean
#date
#datetime
#decimal
#float
#integer
#text
#time
#OPTIONS CAN BE:
#:limit => size
#default => value
#:null => true/false
#AND the following 2 for decimal columns:
#:precision => number
#scale => number

#t.timestamps below is exactly as writing this:

#t.datetime created_at
#t.datetime updated_at
 t.timestamps #this is for the created_at and updated_at columns to be created and managed
automatically.

end

end

4) to run a migration, i.e. to make the change to the database, run:

rake db:migrate RAILS_ENV = production

If the environment for the migration is the development (which usually is) then the RAILS_ENV by default has value
development so it is not needed in the command.

rake db:migrate says to Rails to try and run ALL the migrations that have not be ran already, not only the last one
we may just have created!

AFTER RUNNING A MIGRATION, RAILS A L W A Y S updates the db/schema.rb with the current state of our
database. So this file always represents the current stateof our database.

To REVERT database to a previous version some migrations before for example at its initial state before ANY
migrations, we can do this:

rake db:migrate VERSION=0

To see a report about the active migrations and the inactive ones these that has not been ran yet we have
the command:

rake db:migrate:status

which shows a list of the up migrations the active ones and the down migrations the inactive ones.

If we want to run a specific migration, and not ALL the inactive ones, which is what the rake db:migrate does by
default, we run the command:

Rake db:migrate VERSION=timestamp_of_wanted_migration_here

ALSO, THE ABOVE COMMAND IS THE WAY TO REVERT BACK TO THIS SPECIFIC STATE OF DB, AND REVERTANY
CHANGES TO THE DB THAT HAVE BEEN MADE AFTER THIS VERSION!

5) All migration methods:

create_table(table, options) do |t|

drop_table(table)
rename_table(table, new_name)

add_column(table, column, type, options)

remove_column(table, column)
rename_column(table, column, new_name)
change_column(table, column, type, options)

add_index(table, column, options)

remove_index(table, column)
#INDEX OPTIONS:
#:unique => true/false
#name => custom_index_here

execute(any [raw] SQL string here)

AN EXAMPLE IS SHOWN BELOW:

6) Migration problems and solving them

If for example on the above screenshot on the up method we had a bug on 4rth line and we had written
rename_column(admin_users, broken_column_password, hashed_password)

then rails would start the migration, it would SUCCESSFULLY DO the rename_table, add_column and change_column
commands and at the rename_column command it would GIVE AN ERROR AND WOULD ABORT the migration!
HOWEVER, NO ROLLBACK WILL OCCUR!!! The 3 lines above the error will have made their impact in the database!!!
So, for example now there will be a table admin_users an NO table users.

The solution in these cases, is to fix the bug in the line that it is AND COMMENT OUT THE SUCCESSFULLY EXECUTED
CODE LINES THAT WERE ABOVE THE LINE WITH THE BUG TO GET BACK ON TRACK AND TRY TO RUN THE
MIGRATION AGAIN!!
Another solution would be to go and write raw SQL in the database in order to revert it back to the state before the
migration even started, but THAT SHOULD BE THE LAST RESORT.

Thats why migrations should always be small and concise (e.g. dont do 4 create_table in 1 migration).