DEV Community: Ian Vaughan

Moving from direct has_many to has_many :through

Ian Vaughan — Fri, 08 Jan 2021 11:06:42 +0000

A common Rails model association is a one-to-many, has_many Association.

This allows a Company to have many Users, but a User can only be in one Company. This looked like this in our app:

class Company < ApplicationRecord 
  has_many :users, dependent: :destroy
end

class User < ApplicationRecord 
  belongs_to :company
end

We also have a nice little extra has_many defined on the same relationship that is scoped to a particular type of user.

class Company < ApplicationRecord 
  has_many :directors, -> { where(role: 'director') }, class_name: 'User'
end

Changes

We wanted to allow one user to belong to many companies, and still keep one company can have many users. This is called a many-to-many association, and there a few ways to do this with Rails.
I think the most complex but most powerful is has_many :through Association. Its quite well documented above and other places, but here is what I have working:

class Company < ApplicationRecord 
  has_many :_company_users, dependent: :destroy
  has_many :users, through: :_company_users
end

class User < ApplicationRecord 
  has_many :_company_users
  has_many :companies, through: :_company_users
end

class CompanyUser < ApplicationRecord
  belongs_to :company
  belongs_to :user, dependent: :destroy
end

Note: I've declared the intermediate relationships with an underscore, eg _company_users, to denote they are internal plumbing and not for general usage.
That way when looking at the classes public methods they are not grouped with the normal accessors.
Although they can still be used as normal.

The CompanyUser is the join table, which can house other attributes as you need, like user permissions etc.

The difficulty came when addressing the scoped association. First query is to get the join table results for the scope (_directors_users), and then we need a named accessor that uses that to get the end result (directors). What was needed was the source to get the SQL correct :

class Company < ApplicationRecord 
  has_many :_directors_users, -> { joins(:user).where(role: 'director') }, class_name: 'CompanyUser'
  has_many :directors, through: :_directors_users, source: :user
end

The schema now looks like this:

Playground

I wanted to explore how has_many / with scope / through all worked, so for future me and anyone else interested, here are a few combinations and the resulting SQL.

  has_many :directors_users, -> { where(id: '1') }, class_name: 'User'
  # SELECT "users".* FROM "users" WHERE "users"."company_id" = 1685 AND "users"."id" = 1

  has_many :directors_users, -> { where(role: 'director') }, class_name: 'User'
  # SELECT "users".* FROM "users" WHERE "users"."company_id" = 1686 AND "users"."role" = 'director'

  has_many :directors_users, -> { joins(:company_users).where(role: 'director') }, class_name: 'User'
  # SELECT "users".* FROM "users" INNER JOIN "company_users" 
  #                               ON "company_users"."user_id" = "users"."id"
  #                               WHERE "users"."company_id" = 1683 AND "users"."role" = 'director'"

  has_many :directors_users, -> { joins(:company_users).where(role: 'director') }
  # NameError: uninitialized constant Company::DirectorsUser

  has_many :directors_users, -> { joins(:company_users).where(role: 'director') }, class_name: 'CompanyUser'
  # ActiveRecord::ConfigurationError: Can't join 'CompanyUser' to association named 'company_users'; perhaps you misspelled it?

  has_many :directors_users, -> { where(id: '1') }, class_name: 'User', source: :users
  # SELECT "users".* FROM "users" WHERE "users"."company_id" = 1691 AND "users"."id" = 1

  has_many :directors_users, -> { joins(:user).where(role: 'director') }, class_name: 'CompanyUser'
  # SELECT "company_users".* FROM "company_users" INNER JOIN "users" 
  #                                               ON "users"."id" = "company_users"."user_id"
  #                                               WHERE "company_users"."company_id" = 1690 
  #                                               AND "company_users"."role" = 'director'"
  has_many :directors_users, -> { joins(:user).where('users.role': 'director') }, class_name: 'CompanyUser'
  # SELECT "company_users".* FROM "company_users" INNER JOIN "users" 
  #                                               ON "users"."id" = "company_users"."user_id" 
  #                                               WHERE "company_users"."company_id" = 1694 
  #                                               AND "users"."role" = 'director'

Moving has_many_attached to a different model

Ian Vaughan — Fri, 14 Aug 2020 12:59:22 +0000

has_many_attached is an amazingly easy to way to save attachments to your models.

Specifies the relation between multiple attachments and the model.

-- https://edgeapi.rubyonrails.org/classes/ActiveStorage/Attached/Model.html#method-i-has_many_attached

But with all that ease, comes a load of magic under the hood, none of which you really need to care about for day to day usage.
Until you need to do something more advance, like move the association from one model to another...

Under the covers, this relationship is implemented as a has_many association to a ActiveStorage::Attachment record and a has_many-through association to a ActiveStorage::Blob record. These associations are available as photos_attachments and photos_blobs. But you shouldn't need to work with these associations directly in most circumstances.

Setup

Say we have a Company model with some filed_accounts attached:

class Company < ApplicationRecord
  has_many_attached :filed_accounts
end

To get setup from scratch or more info see here: https://edgeguides.rubyonrails.org/active_storage_overview.html#setup

Database

Currently the schema looks like:

And data

Company

id	name	...
28	Pipe Piper	...

ActiveStorage::Attachment

id	name	record_type	record_id	blob_id
20	'filed_accounts'	'Company'	28	30
23	'filed_accounts'	'Company'	28	33

ActiveStorage::Blob

id	...
30	...
33	...

See the ActiveStorage::Attachment#record_id points to our model and #blob_id to the Blob.

Usage

Attachments are easy to use, we can see the Attached :

> Company.find(28).filed_accounts
=> #<ActiveStorage::Attached::Many:
 @name="filed_accounts",
 @record=
  #<Company:
   id: 28,
   ...>>

More interesting are the actual attachments :

> Company.find(28).filed_accounts.attachments
=> [<ActiveStorage::Attachment: id: 20, name: "filed_accounts", record_type: "Company", record_id: 28, blob_id: 30>,
    <ActiveStorage::Attachment: id: 23, name: "filed_accounts", record_type: "Company", record_id: 28, blob_id: 33>]

Which we can see under the hood goes via the record_id and record_type :

Company.find(28).filed_accounts.attachments.to_sql
=> "SELECT \"active_storage_attachments\".* 
    FROM \"active_storage_attachments\" 
    WHERE \"active_storage_attachments\".\"record_id\" = 28 
      AND \"active_storage_attachments\".\"record_type\" = 'Company' 
      AND \"active_storage_attachments\".\"name\" = 'filed_accounts'"

We can also see the blobs which is the actual data

> Company.find(28).filed_accounts.blobs
=> [#<ActiveStorage::Blob:
  id: 30,
  key: "udi431282hya1l68dt16fi4ee4zd",
  filename: "my_doc.pdf",
  content_type: "application/pdf",
  metadata: {"identified"=>true, "analyzed"=>true},
  byte_size: 167766,
  checksum: "jy+j/AFI9nc8+5afLEpqSw==">,
 #<ActiveStorage::Blob:
  id: 33,
  key: "mn25fl9u08lwsq8lbvm5wo93whpn",
  filename: "my_doc2.pdf",
  content_type: "application/pdf",
  metadata: {"identified"=>true, "analyzed"=>true},
  byte_size: 77490,
  checksum: "0n98/tzywedKJzOT/X0vSw==">]

And under the hood the blobs goes via the attachments :

> Company.find(28).filed_accounts.blobs.to_sql
=> "SELECT \"active_storage_blobs\".* 
    FROM \"active_storage_blobs\" 
    INNER JOIN \"active_storage_attachments\" 
    ON \"active_storage_blobs\".\"id\" = \"active_storage_attachments\".\"blob_id\" 
    WHERE \"active_storage_attachments\".\"record_id\" = 28 
      AND \"active_storage_attachments\".\"record_type\" = 'Company' 
      AND \"active_storage_attachments\".\"name\" = 'filed_accounts'"

Move it to a different model

And we want to move the attachments to the User model, first, add the has_many_attached :

 class User < ApplicationRecord
+  has_many_attached :filed_accounts
 end

We now need to update the ActiveStorage::Attachment rows:

record_type from Company to User and
record_id from the Company id 28 to the User id linked to the company.

So in a migration file:

def up
  Company.all.each do |company|
    company.filed_accounts.attachments.update_all(
      record_type: 'User', 
      record_id: company.user.id
    )
  end
end

(You can make the migration more efficient if you wish!)

NGROK on Rails

Ian Vaughan — Fri, 07 Feb 2020 18:37:44 +0000

When writing code to handle incoming webhooks, it's a good idea to actually get the service to send some real ones in, the best API docs in the world won't beat a real integration!

A Webhook is just a POST request to your server, when something happens on a third party service.

The problem comes when you want to test those webhooks locally, to actually see a real request and payload, and see how your controller handles it, maybe debug some payload param, etc.

The issue is that the service cannot call your local computer, as its not publically on the internet. This is where ngork comes in. It will open the default 8080 port on your machine, and direct any traffic to that port to a chosen localhost port. eg, to open up your default rails app :

$ ngrok http 3000

That command starts ngrok which opens its status screen which looks like:

It even has a nice web UI which can be used to view, edit and replay requests, very cool:

After starting ngrok above, the rails app on my machine is open to the world on the hostname 9fdb5bc4.ngrok.io (you can assume I've closed that by the time you read this!)

Your service provider will have a webhooks config page, where you can put the hostname of the service for it to post to. eg

So all is great, you get your webhook fired off, which routes to your rails app, which reports this:

(You will only see the log output version of that on the rails s console!)

So it says add the hostname to the config, but we can do one better than that. If we add the following into ./config/environments/development.rb :

  config.hosts << ENV['NGROK_HOST'] if ENV['NGROK_HOST'].present?

Then we don't need to change our code when we restart ngrok (each time it starts it will give a random hostname, unless you pay!)

With that config line in place, all we need to do before starting rails is to export aa var, eg:

export NGROK_HOST=a234c154.ngrok.io

Then it will be added to rails cofig.hosts so it accepts requests.