Group items tagged

allowing your schema and changes to be database independent.

each migration as being a new 'version' of the database

each migration modifies it to add or remove tables, columns, or entries

roll this migration back, it will remove the table

timestamps macro adds two columns, created_at and updated_at

On databases that support transactions with statements that change the schema, migrations are wrapped in a transaction

reversible

use up and down instead of change

Migrations are stored as files in the db/migrate directory, one for each migration class.

a UTC timestamp identifying

Rails uses this timestamp to determine which migration should be run and in what order

"AddXXXToYYY" or "RemoveXXXFromYYY"

use a Ruby DSL

column type as references

part_number:string:index

a migration to remove a column

"CreateXXX"

change_column_null

AddUserRefToProducts

:references

produce join tables if JoinTable is part of the name

CreateJoinTable

The model and scaffold generators will create migrations appropriate for adding a new model.

enclosed by curly braces and follow the field type

create_table

By default, create_table will create a primary key called id

add an index on the new column

when using MySQL, the default is ENGINE=InnoDB

create_join_table creates an HABTM (has and belongs to many) join table

create_join_table also accepts a block

change_table, used for changing existing tables

remove

rename

add_column

change_column

remove_column

change_column_default

place an SQL fragment in the :options option.

limit

precision

scale

polymorphic

default

index

add_foreign_key

use the old style of migration using up and down methods instead of the change method.

.connection.execute

remove_column is reversible if you supply the column type as the third argument

Complex migrations may require processing that Active Record doesn't know how to reverse

reversible

Using reversible will ensure that the instructions are executed in the right order too.

add_column add_foreign_key add_index add_reference add_timestamps change_column_default (must supply a :from and :to option) change_column_null create_join_table create_table disable_extension drop_join_table drop_table (must supply a block) enable_extension remove_column (must supply a type) remove_foreign_key (must supply a second table) remove_index remove_reference remove_timestamps rename_column rename_index rename_table

:column_options option

have the option :null set to false by default

By default, the name of the join table comes from the union of the first two arguments provided to create_join_table

If the column names can not be derived from the table names, you can use the :column and :primary_key options.

figure out the column name

foreign key for a specific column

foreign key by name

should use reversible or write the up and down methods instead of using the change method

If your migration is irreversible, you should raise ActiveRecord::IrreversibleMigration from your down method.

DontUseConstraintForZipcodeValidationMigration

rails db:migrate

specify a target version

all migrations up to and including 20080906120000

run the down method on all the migrations down to, but not including, 20080906120000

rails db:rollback

db:migrate:redo task is a shortcut for doing a rollback and then migrating back up again

STEP parameter

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.

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.

revert method can be helpful when writing a new migration to undo previous migrations in whole or in part

require_relative

revert

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

you can execute custom SQL statements, the schema dumper cannot reconstitute those statements from the database

db:structure:dump

set in config/application.rb by the config.active_record.schema_format setting, which may be either :sql or :ruby.

check them into source control.

db/schema.rb contains the current version number of the database

Validations such as validates :foreign_key, uniqueness: true are one way in which models can enforce data integrity

The :dependent option on associations allows models to automatically destroy child objects when the parent is destroyed.

Migrations can also be used to add or modify data

Initial

To add initial data after a database is created, Rails has a built-in 'seeds' feature that makes the process quick and easy.

db/seeds.rb

rails db:seed

created

saved

updated

deleted

validated

loaded

use a macro-style class method to register them as callbacks

self.name = login.capitalize if name.blank?

registered to only fire on certain life cycle events

all the available Active Record callbacks,

after_initialize callback will be called whenever an Active Record object is instantiated, either by directly using new or when a record is loaded from the database

after_find callback will be called whenever Active Record loads a record from the database.

after_touch callback will be called whenever an Active Record object is touched.

belongs_to :company, touch: true

methods trigger callbacks

after_find callback is triggered by the following finder methods

after_initialize callback is triggered every time a new object of the class is initialized

As you start registering new callbacks for your models, they will be queued for execution

The whole callback chain is wrapped in a transaction

Callbacks work through model relationships, and can even be defined by them.

As with validations, we can also make the calling of a callback method conditional on the satisfaction of a given predicate

When using the :if option, the callback won't be executed if the predicate method returns false; when using the :unless option, the callback won't be executed if the predicate method returns true.

with a Symbol

with a String

with a Proc

using eval and hence needs to contain valid Ruby code.

mix both :if and :unless in the same callback declaration

needed to instantiate a new PictureFileCallbacks object, since we declared our callback as an instance method.

Active Record makes it possible to create classes that encapsulate the callback methods, so it becomes very easy to reuse them.

won't be necessary to instantiate

after_commit

after_rollback

very similar to the after_save callback except that they don't execute until after database changes have either been committed or rolled back

delete_picture_file_from_disk

after_commit

If anything raises an exception after the after_destroy callback is called and the transaction rolls back, the file will have been deleted and the model will be left in an inconsistent state

don't supply the :on option the callback will fire for every action.

The after_commit and after_rollback callbacks are guaranteed to be called for all models created, updated, or destroyed within a transaction block.

Associations are implemented using macro-style calls, so that you can declaratively add features to your models

A belongs_to association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model.

belongs_to

A has_one association also sets up a one-to-one connection with another model, but with somewhat different semantics (and consequences).

belongs_to

A has_many association indicates a one-to-many connection with another model.

This association indicates that each instance of the model has zero or more instances of another model.

belongs_to

A has_many :through association is often used to set up a many-to-many connection with another model

This association indicates that the declaring model can be matched with zero or more instances of another model by proceeding through a third model.

through:

through:

The collection of join models can be managed via the API

new join models are created for newly associated objects, and if some are gone their rows are deleted.

The has_many :through association is also useful for setting up "shortcuts" through nested has_many associations

A has_one :through association sets up a one-to-one connection with another model. This association indicates that the declaring model can be matched with one instance of another model by proceeding through a third model.

A has_and_belongs_to_many association creates a direct many-to-many connection with another model, with no intervening model.

id: false

The has_one relationship says that one of something is yours

using t.references :supplier instead.

declare a many-to-many relationship is to use has_many :through. This makes the association indirectly, through a join model

set up a has_many :through relationship if you need to work with the relationship model as an independent entity

set up a has_and_belongs_to_many relationship (though you'll need to remember to create the joining table in the database).

use has_many :through if you need validations, callbacks, or extra attributes on the join model

With polymorphic associations, a model can belong to more than one other model, on a single association.

a polymorphic belongs_to declaration as setting up an interface that any other model can use.

In designing a data model, you will sometimes find a model that should have a relation to itself

add a references column to the model itself

All of the association methods are built around caching, which keeps the result of the most recent query available for further operations.

it is a bad idea to give an association a name that is already used for an instance method of ActiveRecord::Base. The association method would override the base method and break things.

belongs_to associations you need to create foreign keys

has_and_belongs_to_many associations you need to create the appropriate join table

So a join between customer and order models will give the default join table name of "customers_orders" because "c" outranks "o" in lexical ordering.

For example, one would expect the tables "paper_boxes" and "papers" to generate a join table name of "papers_paper_boxes" because of the length of the name "paper_boxes", but it in fact generates a join table name of "paper_boxes_papers" (because the underscore '' is lexicographically _less than 's' in common encodings).

id: false

pass id: false to create_table because that table does not represent a model

By default, associations look for objects only within the current module's scope.

will work fine, because both the Supplier and the Account class are defined within the same scope.

To associate a model with a model in a different namespace, you must specify the complete class name in your association declaration:

class_name

class_name

Active Record provides the :inverse_of option

Every association will attempt to automatically find the inverse association and set the :inverse_of option heuristically (based on the association name)

In database terms, this association says that this class contains the foreign key.

In all of these methods, association is replaced with the symbol passed as the first argument to belongs_to.

(force_reload = false)

The association method returns the associated object, if any. If no associated object is found, it returns nil.

the cached version will be returned.

The association= method assigns an associated object to this object.

Behind the scenes, this means extracting the primary key from the associate object and setting this object's foreign key to the same value.

The build_association method returns a new object of the associated type

The create_association method returns a new object of the associated type

raises ActiveRecord::RecordInvalid if the record is invalid.

dependent

counter_cache

:autosave :class_name :counter_cache :dependent :foreign_key :inverse_of :polymorphic :touch :validate

finding the number of belonging objects more efficient.

Although the :counter_cache option is specified on the model that includes the belongs_to declaration, the actual column must be added to the associated model.

:destroy, when the object is destroyed, destroy will be called on its associated objects.

The :inverse_of option specifies the name of the has_many or has_one association that is the inverse of this association

set the :touch option to :true, then the updated_at or updated_on timestamp on the associated object will be set to the current time whenever this object is saved or destroyed

specify a particular timestamp attribute to update

If you set the :validate option to true, then associated objects will be validated whenever you save this object

where includes readonly select

make your code somewhat more efficient

no need to use includes for immediate associations

will be read-only when retrieved via the association

The select method lets you override the SQL SELECT clause that is used to retrieve data about the associated object

using the association.nil?

In database terms, this association says that the other class contains the foreign key.

the cached version will be returned.

:as :autosave :class_name :dependent :foreign_key :inverse_of :primary_key :source :source_type :through :validate

Setting the :as option indicates that this is a polymorphic association

:nullify causes the foreign key to be set to NULL. Callbacks are not executed.

It's necessary not to set or leave :nullify option for those associations that have NOT NULL database constraints.

The :source_type option specifies the source association type for a has_one :through association that proceeds through a polymorphic association.

The :source option specifies the source association name for a has_one :through association.

The :through option specifies a join model through which to perform the query

more efficient by including representatives in the association from suppliers to accounts

When you assign an object to a has_one association, that object is automatically saved (in order to update its foreign key).

If either of these saves fails due to validation errors, then the assignment statement returns false and the assignment itself is cancelled.

If the parent object (the one declaring the has_one association) is unsaved (that is, new_record? returns true) then the child objects are not saved.

If you want to assign an object to a has_one association without saving the object, use the association.build method

collection(force_reload = false) collection<<(object, ...) collection.delete(object, ...) collection.destroy(object, ...) collection=(objects) collection_singular_ids collection_singular_ids=(ids) collection.clear collection.empty? collection.size collection.find(...) collection.where(...) collection.exists?(...) collection.build(attributes = {}, ...) collection.create(attributes = {}) collection.create!(attributes = {})

In all of these methods, collection is replaced with the symbol passed as the first argument to has_many, and collection_singular is replaced with the singularized version of that symbol.

The collection<< method adds one or more objects to the collection by setting their foreign keys to the primary key of the calling model

The collection.delete method removes one or more objects from the collection by setting their foreign keys to NULL.

objects will be destroyed if they're associated with dependent: :destroy, and deleted if they're associated with dependent: :delete_all

The collection.destroy method removes one or more objects from the collection by running destroy on each object.

The collection_singular_ids method returns an array of the ids of the objects in the collection.

The collection_singular_ids= method makes the collection contain only the objects identified by the supplied primary key values, by adding and deleting as appropriate

The default strategy for has_many :through associations is delete_all, and for has_many associations is to set the foreign keys to NULL.

The collection.clear method removes all objects from the collection according to the strategy specified by the dependent option

uses the same syntax and options as ActiveRecord::Base.find

The collection.where method finds objects within the collection based on the conditions supplied but the objects are loaded lazily meaning that the database is queried only when the object(s) are accessed.

The collection.build method returns one or more new objects of the associated type. These objects will be instantiated from the passed attributes, and the link through their foreign key will be created, but the associated objects will not yet be saved.

The collection.create method returns a new object of the associated type. This object will be instantiated from the passed attributes, the link through its foreign key will be created, and, once it passes all of the validations specified on the associated model, the associated object will be saved.

:as :autosave :class_name :dependent :foreign_key :inverse_of :primary_key :source :source_type :through :validate

:nullify causes the foreign keys to be set to NULL. Callbacks are not executed.

where includes readonly select

:conditions :through :polymorphic :foreign_key

By convention, Rails assumes that the column used to hold the primary key of the association is id. You can override this and explicitly specify the primary key with the :primary_key option.

The :source option specifies the source association name for a has_many :through association.

You only need to use this option if the name of the source association cannot be automatically inferred from the association name.

The :source_type option specifies the source association type for a has_many :through association that proceeds through a polymorphic association.

The :through option specifies a join model through which to perform the query.

has_many :through associations provide a way to implement many-to-many relationships,

By default, this is true: associated objects will be validated when this object is saved.

where extending group includes limit offset order readonly select uniq

If you use a hash-style where option, then record creation via this association will be automatically scoped using the hash

The extending method specifies a named module to extend the association proxy.

Association extensions

The group method supplies an attribute name to group the result set by, using a GROUP BY clause in the finder SQL.

more efficient by including line items in the association from customers to orders

The limit method lets you restrict the total number of objects that will be fetched through an association.

The offset method lets you specify the starting offset for fetching objects via an association

The order method dictates the order in which associated objects will be received (in the syntax used by an SQL ORDER BY clause).

Use the distinct method to keep the collection free of duplicates.

mostly useful together with the :through option

-> { distinct }

.all.inspect

If you want to make sure that, upon insertion, all of the records in the persisted association are distinct (so that you can be sure that when you inspect the association that you will never find duplicate records), you should add a unique index on the table itself

Do not attempt to use include? to enforce distinctness in an association.

When you assign an object to a has_many association, that object is automatically saved (in order to update its foreign key).

If any of these saves fails due to validation errors, then the assignment statement returns false and the assignment itself is cancelled.

If the parent object (the one declaring the has_many association) is unsaved (that is, new_record? returns true) then the child objects are not saved when they are added

assign an object to a has_many association without saving the object, use the collection.build method

collection(force_reload = false) collection<<(object, ...) collection.delete(object, ...) collection.destroy(object, ...) collection=(objects) collection_singular_ids collection_singular_ids=(ids) collection.clear collection.empty? collection.size collection.find(...) collection.where(...) collection.exists?(...) collection.build(attributes = {}) collection.create(attributes = {}) collection.create!(attributes = {})

If the join table for a has_and_belongs_to_many association has additional columns beyond the two foreign keys, these columns will be added as attributes to records retrieved via that association.

If you require this sort of complex behavior on the table that joins two models in a many-to-many relationship, you should use a has_many :through association instead of has_and_belongs_to_many.

The collection.delete method removes one or more objects from the collection by deleting records in the join table

The collection.destroy method removes one or more objects from the collection by running destroy on each record in the join table, including running callbacks.

The collection.clear method removes every object from the collection by deleting the rows from the joining table.

The collection.find method finds objects within the collection. It uses the same syntax and options as ActiveRecord::Base.find.

The collection.where method finds objects within the collection based on the conditions supplied but the objects are loaded lazily meaning that the database is queried only when the object(s) are accessed.

The collection.exists? method checks whether an object meeting the supplied conditions exists in the collection.

The collection.build method returns a new object of the associated type.

The collection.create method returns a new object of the associated type.

it passes all of the validations specified on the associated model

:association_foreign_key :autosave :class_name :foreign_key :join_table :validate

The :foreign_key and :association_foreign_key options are useful when setting up a many-to-many self-join.

Rails assumes that the column in the join table used to hold the foreign key pointing to the other model is the name of that model with the suffix _id added.

If you set the :autosave option to true, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object.

By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix _id added.

By default, this is true: associated objects will be validated when this object is saved.

where extending group includes limit offset order readonly select uniq

set conditions via a hash

In this case, using @parts.assemblies.create or @parts.assemblies.build will create orders where the factory column has the value "Seattle"

using a GROUP BY clause in the finder SQL.

Use the uniq method to remove duplicates from the collection.

assign an object to a has_and_belongs_to_many association, that object is automatically saved (in order to update the join table).

If any of these saves fails due to validation errors, then the assignment statement returns false and the assignment itself is cancelled.

If the parent object (the one declaring the has_and_belongs_to_many association) is unsaved (that is, new_record? returns true) then the child objects are not saved when they are added.

If you want to assign an object to a has_and_belongs_to_many association without saving the object, use the collection.build method.

Normal callbacks hook into the life cycle of Active Record objects, allowing you to work with those objects at various points

define association callbacks by adding options to the association declaration

stack callbacks on a single event by passing them as an array

If a before_add callback throws an exception, the object does not get added to the collection.

if a before_remove callback throws an exception, the object does not get removed from the collection

extend these objects through anonymous modules, adding new finders, creators, or other methods.

order_number

use a named extension module

proxy_association.owner returns the object that the association is a part of.

objects carry both persistent data and behavior which operates on that data

Object-Relational Mapping, commonly referred to as its abbreviation ORM, is a technique that connects the rich objects of an application to tables in a relational database management system

Represent associations between these models

Validate models before they get persisted to the database

The idea is that if you configure your applications in the very same way most of the times then this should be the default way.

use the ActiveRecord::Base.table_name= method to specify the table name

Foreign keys - These fields should be named following the pattern singularized_table_name_id

Primary keys - By default, Active Record will use an integer column named id as the table's primary key

created_at

updated_at

(table_name)_count - Used to cache the number of belonging objects on associations.

Single Table Inheritance (STI)

Object Relational Mapping

class_name.yml

ActiveRecord::Base.primary_key=

CRUD is an acronym for the four verbs we use to operate on data: Create, Read, Update and Delete.

new method will return a new object

create will return the object and save it to the database.

Using the new method, an object can be instantiated without being saved

user.save will commit the record to the database

update_all class method

an Active Record object can be destroyed which removes it from the database

Validation is a very important issue to consider when persisting to database, so the methods create, save and update take it into account when running: they return false when validation fails and they didn't actually perform any operation on database.

Active Record callbacks allow you to attach code to certain events in the life-cycle of your models

Rails keeps track of which files have been committed to the database and provides rollback features

Convention over Configuration

view templates are written in a language called ERB (Embedded Ruby) which is converted by the request cycle in Rails before being sent to the user.

Each action's purpose is to collect information to provide it to a view.

A view's purpose is to display this information in a human readable format.

routing file which holds entries in a special DSL (domain-specific language) that tells Rails how to connect incoming requests to controllers and actions.

You can create, read, update and destroy items for a resource and these operations are referred to as CRUD operations

A controller is simply a class that is defined to inherit from ApplicationController.

If not found, then it will attempt to load a template called application/new. It looks for one here because the PostsController inherits from ApplicationController

:formats specifies the format of template to be served in response. The default format is :html, and so Rails is looking for an HTML template.

:handlers, is telling us what template handlers could be used to render our template.

When you call form_for, you pass it an identifying object for this form. In this case, it's the symbol :post. This tells the form_for helper what this form is for.

that the action attribute for the form is pointing at /posts/new

When a form is submitted, the fields of the form are sent to Rails as parameters.

parameters can then be referenced inside the controller actions, typically to perform a particular task

params method is the object which represents the parameters (or fields) coming in from the form.