Rails for Zombies 2 Level 2 Models - mikesabat/LR_HF GitHub Wiki

Back to Models

-3 Named Scope: If we're continuously querying for a specific variable, we can move that query to the model instead of the controller. The example they give, in the Zombies model, query for rotting and set it to a variable, instead of creating the variable in the controller.

/model >> scope :rotting, where(rotting: true)

scope :fresh, where("age < 20")

scope :recent, order(created_at_desc).limit(3)

-4 Callbacks - are only in the model. Callbacks allow you to call methods before or after certain things happen. For example:

When Zombie age > 20, set rotting to true. If we wrote this in the controller we would do an if statements

if @zombie.age > 20

[email protected] = true

end

This won't fly. I think that we don't want to make Model changes in the controller. We need to write model methods for this?? One reason is that we may update the Zombie outside of this method, and if we update the zombie somewhere eles, this method won't be called. So we want to go to the model and make sure that before we save a zombie we run this check. We use a call back for this.

So we move the method to the model.

before_save :make_rotting

def make_rotting

__if age > 20

____self.rotting = true

__end

end

Model Methods are a little different. When we look for age in the method, we are reading. So first it will look for age in the method and it won't find it, then it will look for age in the instance of the variable that we're saving, and it will find it there. So we can use 'age'. But when we set the variable for rotting, we need to use self.rotting. Self. allows you to write to variables. If we didn't use self, we would be caught in this method. Self. lets us out of the method and set to the instance of the variable, out of this method.

-5 Returning false on a callback will halt whatever is happening.

-6 All Callback available in an ActiveRecord Model

before_save/after_save before_validation/after_validation before_destroy/after_destroy before_create/after_create before_update/after_update

-8. Relationships: has_one: relationships show how models related to each other. So there needs to be two models for their to be relationships.

Foreign Key Index connects one model to another based on the ID. In the migration, as a new function >> add_index :this_model, :relative_id

The relationship is first noted in the migration above. We need to then specify in the respective models. Brain Model = belongs_to :zombie

Zombie Model = has_one :brain (examples from the video)

If we want the Zombie brain to be dependent on the fact that the Zombie exists, we need to note that. For instance if we want the brain to be destroyed when the zombie is destroyed we need to put that in the model. In the zombie model the relationship should read.

has_one :brain dependent: :destroy

-11. Relationship options there are a lot. Check the documentation. Some examples:

dependent: :destroy - the related object will be destroyed if the dependent object is destroyed

foreign_key: :new_id -- will change for foreign key

validate: true -- rails will validate both objects

-12. Relationship, include option: an N+1 query is bad. It means that we're querying the database each time for the next ID instead of bringing all of the queries in at once.

In the controller index action, one would normally set @zombies = Zombie.all in the view, we'd want to list @zombie.name and then @zombie.brain.flavor -- this would be the N+1 problem. To fix, we want to add an Include Option to the controller. @zombies = Zombie.includes(:brain).all - this brings back the Zombie and their brain.

-13. has_many_through - this is pretty confusing. If models can have many objects of another model == account managers can have many customers... we create a third table to help them relate. Watch the video