This ain't for kids anymore. Direct your children this way or that way. Everybody else, let's go.

First off, we're not using sqlite3 anymore, ew what are you, a baby? No. All the babies have left. You're an adult. Adults want to deploy their projects. What do we need to deploy our projects, I hear you ask? Postgres fool.

Say you want to make a site that allows users to make playlists, please. Oh good, that's what you wanted to make? Phew, I didn't want to come up with another example.

So here's the thing, an Artist has_many songs, and a song belongs_to one Artist. In this universe, it's canon that collaborations never happen, ok? A song, however, also beongs_to one album. That album has_many songs. The Album belongs_to an Artist, the Artist has_many albums.

A user has_many mixtapes, and mixtapes belong_to that single user. No collabs here either, this is you and your laptop not Spotify. In that relationship for example, the mixtape would have the foreign key. The owner of the thing does not have the foreign key. The thing which belongs_to, does. However, in an annoying complication, the mixtape also has_many songs. That makes it a HABT relationship. Has and belongs to many. There's a polyamory joke in there somewhere but we don't have time for that.

Back to our new elephant friend. Terminal command rails new radio --skip-git -d postgresql. Omit skip git if needed. cd radio rails db:create. rails db will now drop you into Postgres if that's what you've got running. Also you might notice you can't see your database in the db folder anymore, but an elephant never forgets so it's fine. Don't worry about it.

If you were a fan of the .schema command in sqlite3, grow up. We're using \d now. CTR D outta there anyway, we don't even have any models yet.

Now rails generate model Song title:text album_id:integer artist_id:integer. Woah look at you go, generating the model and the migration. Unless you stuffed it up, check your migrations folder. Mine looked like this.

class CreateSongs < ActiveRecord::Migration[5.2]
  def change
    create_table :songs do |t|
      t.text :title
      t.integer :album_id
      t.integer :artist_id

      t.timestamps
    end
  end
end

It's got a foreign key and everything! Aw yis. rails db:migrate. Let's do a sanity check and rails db then \d. You should see the songs table. Rails console and Song.new to be sure it's got all ten fingers and toes. A healthy baby song, nice.

rails generate model Artist name:text image:text, check the migration folder, and onto rails generate model Album title:text image:text. rails generate model Mixtape title:text user_id:integer then rails:db migrate. Look at all those models, you busy thing, you.

Ready for the big one? rails generate model User email:text. Because rails made our models for us, they're connected to ActiveRecord::Base via application_record in our models folder. That's fine though, since we're all inheriting from it, and it's inheriting from ActiveRecord::Base. It looks like this.

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

Let's go and make those connections. In song.rb. You'll notice it inheriting from ApplicationRecord.

class Song < ApplicationRecord
    belongs_to :artist, :optional => true
    belongs_to :album, :optional => true
    has_and_belongs_to_many :mixtapes
    has_and_belongs_to_many :genres
end

There's a lot going on there, huh? Artists are a bit like that.

class Album < ApplicationRecord
    has_many :songs
end

class Artist < ApplicationRecord
    has_many :songs 
    has_many :genres, :through => :songs
end

class Genre < ApplicationRecord
    has_and_belongs_to_many :songs
end

class Mixtape < ApplicationRecord
    belongs_to :user, :optional => true
    has_and_belongs_to_many :songs
end

Now this one's extra fancy. Feast your eyes on User!

class User < ApplicationRecord
    has_secure_password
    validates :email, :uniqueness => true, :presence => true
    has_many :mixtapes 
end

In the user model I've tackled a few problems that could have been handled elsewhere. Where possible, it's best to fatten up your model and thin out your controller. Basically Thomas the tank engine rules in reverse. The model for example, should be in charge of what is and isn't a valid user. Why? Because Rails, that's why. Rails will take care of the validations for us with very little coding on our part. So let rails be rails, and change the user.rb. User has_secure_password and validates :email, :uniqueness => true, :presence => true, ok?!

Want to see its controller?

class UsersController < ApplicationController
  def new
    @user = User.new
  end
  def create
    @user = User.new user_params
    if @user.save
      session[:user_id] = @user.id
      redirect_to root_path
    else
      render :new
    end
  end
  private
  def user_params
    params.require(:user).permit(:email, :password, :password_confirmation)
  end
end

Busy busy. Let's break her down a bit.

User.save is a predicate method, meaning it'll either be true or false. You can see that in action if you make an invalid user in pry (or irb). Using it and User.new rather than User.create means that we can make a decision based on whether or not a new user was created correctly. We do that by saving it in an instance variable and then using an if else statement to determine what to do next.

 def create
    @user = User.new user_params
    if @user.save
      session[:user_id] = @user.id
      redirect_to root_path
    else
      render :new
    end
  end

In this case, we redirect_to root_path. By using render :new in our else case, we give the user the chance to correct their mistake while giving them a better idea of what went wrong by retaining the parts of the form they filled correctly. Rails, as always, has some great tricks up her sleeve in this department too. If you go and inspect element on your poorly filled out form. Oh fine I suppose I'll show you the form first. Behold, our users/new.html.erb.

<h1>Sign up</h1>

<% if @user.errors.any? %>

    <ol>
        <% @user.errors.full_messages.each do |msg| %>
            <li> <%= msg %> </li>
        <% end %>
    </ol>
<% end %>

<%= form_for @user do |f| %>
    <%= f.label :email %>
    <%= f.email_field :email %>
    <%= f.label :password %>
    <%= f.password_field :password %>
    <%= f.label :password_confirmation %>
    <%= f.password_field :password_confirmation %>
    <%= f.submit "Sign Up!" %>
<% end %>

Anyway, as I was saying, when you inspect element on our form, you'll see a div ruby made for us with the class of 'field_with_errors'. Feel free to add some css to make it more obvious to a user what's gone wrong here.

Another neat trick that gets passed from programmer to programmer is the following.

class ApplicationController < ActionController::Base
    before_action :fetch_user

    def fetch_user
        @current_user = User.find_by :id => session[:user_id] if session[:user_id].present?
        session[:user_id] = nil unless @current_user.present? 
    end
end

This bad boy logs out non-existent users, which can end up being created in the development process if you reseed while a user is logged in, thus creating a horrible bug. Let's just copy-paste it into every project forever and ever, as a community.

This has been baby's teaching babies to code.

I mean, cool adults who know what they're doing.

Goodnight.