you can define supported formats at the class level and tell in the instance the resource to be represented by those formats.
when a request comes, for example with format xml, it will first search for a template at users/index.xml. If the template is not available, it tries to render the resource given (in this case, @users) by calling :to_xml on it
how to render our resources depending on the format AND HTTP verb
By default, ActionController::Responder holds all formats behavior in a method called to_format.
Suddenly we realized that respond_with is useful just for GET requests
it renders the resource based on the HTTP verb and whether it has errors or not
Your controller code just have to send the resource using respond_with(@resource) and respond_with will call ActionController::Responder which will know what to do.
db:setup task will create the database, load the schema and initialize
it with the seed data
db:reset task will drop the database and set it up again. This is
functionally equivalent to rails db:drop db:setup.
run a specific migration up or down, the db:migrate:up and
db:migrate:down
the
RAILS_ENV environment variable
db:migrate
VERBOSE=false will suppress all output.
If you have
already run the migration, then you cannot just edit the migration and run the
migration again: Rails thinks it has already run the migration and so will do
nothing when you run rails db:migrate.
must rollback the migration (for
example with bin/rails db:rollback), edit your migration and then run
rails db:migrate to run the corrected version.
editing existing migrations is not a good idea.
should write a new migration that performs the changes
you require
revert method can be helpful when writing a new migration to undo
previous migrations in whole or in part
require_relative
revert
They are not designed to be
edited, they just represent the current state of the database.
Schema Files for
Schema files are also useful if you want a quick look at what attributes an
Active Record object has
annotate_models gem automatically
adds and updates comments at the top of each model summarizing the schema if
you desire that functionality.
database-independent
multiple databases
db/schema.rb cannot express database specific
items such as triggers, stored procedures or check constraints
you can execute custom SQL statements, the schema dumper cannot
reconstitute those statements from the database