DEV Community: Collin

Building has_one from has_many Associations

Collin — Wed, 22 Jun 2022 14:22:41 +0000

The extent of "options" one could pass to a Rails association macro are somewhat vast and in some cases, at least for me, make one wonder when such "options" would ever be used.

Today, I found myself having to dig into the documentation and google-fu'ing on the fly to try to put into code what a coworker was saying verbally about an approach to building out some model relationships.

To start, let's say that the application we are working on has a model called Account. Let's also say that for billing and shipping purposes, we also want to add an Address model and relate the two models such that:

class Account < ApplicationRecord
  has_many :addresses
end

Disclaimer For the purpose of experimenting and learning I'm choosing not to debate about pros and cons of the implementation as it relates to the scenario at hand.

Now, what we would really like is for our Account model to have this set up but without having to make separate models that will most likely have the exact same attributes:

class Account < ApplicationRecord
  has_many :addresses
  has_one :billing_address
  has_one :shipping_address
end

Let's say we decided test our hand (and mind), and proceed. Our first step is to put the parent model relationship in place along with the finer detailed relationships that we desire. In this case I'm referring to :addresses as the parent model and :billing_address and :shipping_address as the "finer detailed" or (perhaps) child relationships.

Now that we (hopefully) are on level ground with what we want, proceeding, we now have an Account model that looks like so:

class Account < ApplicationRecord
  has_many :addresses
  has_one :billing_address
  has_one :shipping_address
end

The question now is... can we and how do we... make this work?

The short answer is yes, we can make this work. And as we explore how, my hope is that a bit more understanding and curiosity is unlocked for us all.

Let's start making this a reality.

Generate a new rails application however you would normally do so. Then run:

rails g model Account
rails g model Address account:references address_type:integer

We are adding the address_type:integer piece because we are going to make this an enum column with the two options of :billing and :shipping.

Let's migrate rails db:migrate

Now, let's add our enum setup in the Address model like so:

class Address < ApplicationRecord
  belongs_to :account

  enum address_type: [:billing, :shipping]
end

And then setup a has_many relationship in our Account model:

class Account < ApplicationRecord
  has_many :addresses
end

Next let's hop into the rails console bin/rails console and then run:

account = Account.create!
address = Address.create! address_type: "billing", account: account
address = Address.create! address_type: "shipping", account: account

Great, now let's use the account we created to see all the addresses associated to it:

account.addresses
=>                                                                   
[#<Address:0x00007fa1ab6d86f8                                             
  id: 1,                                                                  
  account_id: 1,                                                          
  address_type: "billing",                                                
  created_at: Fri, 01 Apr 2022 02:11:01.334935000 UTC +00:00,             
  updated_at: Fri, 01 Apr 2022 02:11:01.334935000 UTC +00:00>,            
 #<Address:0x00007fa1ab6d3b08                                             
  id: 2,                                                                  
  account_id: 1,                                                          
  address_type: "shipping",                                               
  created_at: Fri, 01 Apr 2022 02:11:15.381033000 UTC +00:00,             
  updated_at: Fri, 01 Apr 2022 02:11:15.381033000 UTC +00:00>]

Ok, this looks promising! Let's try to use our has_one :billing_address association:

account.billing_address
=>
'rescue in compute_class': Rails couldn't find a valid model for BillingAddress association. Please provide the :class_name option on the association declaration. If :class_name is already provided, make sure it's an ActiveRecord::Base subclass. (NameError) 
uninitialized constant Account::BillingAddress (NameError)

Whoops! Rails doesn't seem to be able to find a valid model named BillingAddress which makes sense because we don't have a BillingAddress model. We really would like it if Rails could search on the Addresses table and use information from there to find the billing address record.

As it turns out we can do this by adding a couple of options to the call to has_one :billing_address and has_one :shipping_address.

The first change we will make is to pass in the class_name option which we will then point to the Address class so that Rails will use that model to perform queries on versus trying to use our non-existent BillingAddress model. Update both has_one calls like so:

class Account < ApplicationRecord
  has_many :addresses
  has_one :billing_address, class_name: "Address"
  has_one :shipping_address, class_name: "Address"
end

With this in place let's go back into our Rails console and see what this change will do:

account.billing_address
=>
#<Address:0x00007fa02d699888                                                 
 id: 1,                                                                      
 account_id: 1,                                                              
 address_type: "billing",                                                    
 created_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00,                 
 updated_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00>

Look at that! No error this time and we got an address of type "billing" back. Neat! Let's now try our shipping_address:

account.shipping_address
=>
 id: 1,                                                                   
 account_id: 1,                                                           
 address_type: "billing",                                                 
 created_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00,              
 updated_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00>

Not as exciting this time around. We get back the same record as when we called account.billing_address with in both cases seem to just be returning the first record found.

It would stand to reason that we need some why to tell Rails how to differentiate between the two. Thankfully, by leveraging the optional second argument to our has_one call we can pass in a scope and tell Rails how to found the records we want.

Let's update our Account model as such:

class Account < ApplicationRecord
  has_many :addresses
  has_one :billing_address, -> { where(address_type: "billing") }, class_name: "Address"
  has_one :shipping_address, -> { where(address_type: "shipping") }, class_name: "Address"
end

Now, let's go back into our Rails console one more time and see if this gives us the result we are looking for:

account.billing_address
=>
#<Address:0x00007fb309b8e548                                              
 id: 1,                                                                   
 account_id: 1,                                                           
 address_type: "billing",                                                 
 created_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00,              
 updated_at: Mon, 25 Apr 2022 15:24:48.167699000 UTC +00:00> 

account.shipping_address
=>
#<Address:0x00007fb3088d35c0                                              
 id: 2,                                                                   
 account_id: 1,                                                           
 address_type: "shipping",                                                
 created_at: Mon, 25 Apr 2022 15:29:22.137482000 UTC +00:00,              
 updated_at: Mon, 25 Apr 2022 15:29:22.137482000 UTC +00:00>

We did it! We should take a moment to celebrate this win. After a brief celebration, lets make this a little cleaner and a bit safer.

Safety first so let's start there. We want to help enforce the fact that we only want an account to have one billing or shipping address.

Let's add a validation on the Address model that says that we want to validate the uniqueness of the address_type attribute and scope it to being unique to an Account record. Here's the line addition:

class Address < ApplicationRecord
  # belongs_to :account

  # enum address_type: [:billing, :shipping]

  validates :address_type, uniqueness: { scope: :account_id }
end

As an additional note, it would probably be a good idea to also add a unique constraint at the database level with something like:

add_index :addresses, [:address_type, :account_id], unique: true

Now for the clean up. We can drop the where call in both of the scope: arguments to the has_one macro. We can do this because since we are using enums, Rails gives us some new methods that we can leverage to remove the where calls. Based on the allowed values of the enum field the two scopes that we gain are Address.billing and Address.shipping.

With this new knowledge we can update our has_one scope arguments from:

has_one :billing_address, -> { where(address_type: "billing") }, class_name: "Address"
has_one :shipping_address, -> { where(address_type: "shipping") }, class_name: "Address"

to:

has_one :billing_address, -> { billing }, class_name: "Address"
has_one :shipping_address, -> { shipping }, class_name: "Address"

Pretty slick!

What a really special thing we did here and I hope you found it fun to dig into a few of the options you can pass to your association calls to customize the behavior of them.

Thanks for reading and happy Rubying!

Rails 7.0.0alpha2, esbuild, tailwind and devise

Collin — Sat, 18 Sep 2021 23:48:10 +0000

I recently took a go at starting a new Rails application with Rails 7.0.0alpha2. It went pretty well aside from a few things which I'm going to share with you and point you towards the solutions I came across.

The first step was to get the new version of Rails. You can head on over to https://rubygems.org/gems/rails/versions/7.0.0.alpha2
and grab the install command to get Rails 7 installed.

Next I started a new rails app based off of this video that DHH put out:
https://www.youtube.com/watch?v=JsNtLiph87Y

I ran the same commands but did not get the same results. The main issue was that the build script commands needed for esbuild and tailwind did not get added to the package.json file. A friend pointed out to me, when I shared this on Twitter, what was most likely the cause (the npm version I was using) which you can find in the comments along with the scripts that I had to add before I learned of the possible cause (Thanks again so much Andrea!):

https://twitter.com/collin_jilbert/status/1439316892351705096

With these issues resolved I was off to the races with tailwindcss running in JIT mode as well! Really cool and despite the issues I had, it was still the easiest time I've had installing tailwind in a rails app not to mention getting JIT to work. I basically did nothing :)

Next was an issue when pulling in Devise. Here's the issues you might run into as well if you're following along:

If you run into an issue when running rails generate devise:install, there's a solution branch you can use listed in the thread linked below:

https://github.com/heartcombo/devise/pull/5357#pullrequestreview-656251176

You'll want to add this to your gemfile to use this branch:

gem "devise", github: "ghiculescu/devise", branch: "patch-2"

Run bundle again and then you can move on.

Next you'll probably run into:

Error in lib/devise.rb:316:in get: undefined method constantize for ActiveSupport::Dependencies:Module (NoMethodError)

as noted here, which also provides some guidance on a fix:
https://github.lancex.top/heartcombo/devise#issue-975972076

I ran

bundle open devise

and then made this change to this method which starts on line 315 in devise/lib/devise.rb:
Change from:

def get
  ActiveSupport::Dependencies.constantize(@name)
end

To:

def get
  @name.constantize
end

The next speed bump was an issue I found that was unexpected related to stimulus. After creating a new stimulus controller I noticed, after trying to do a simple console.log in the controller connect() method, that it wasn't firing. After further investigation I found that, with this setup at least, that you can't just manually create a new controller and expect it to work. Instead, if you manually create a new stimulus controller, afterward you need to also remember to run

stimulus:manifest:update

or use the generator to create the controller like so:

./bin/rails generate stimulus [controller]

This may already be known to you but it was new to me as the app I work on at my day job uses webpack and seems to automatically pickup any new stimulus controllers. I'm still learning the in's and out's of the setup at work so be gentle on me in regard to any comments about the previous statement. :)

Hope this helps get you up and running with Rails 7 and the other tools mentioned quickly and enjoying the experience! As time goes on I'm sure a lot of these issues will get worked out thanks to the work by the great folks of the open source community. To all of those folks I send you my warmest thank you!

Rails DB Schema Visualization

Collin — Sun, 03 Jan 2021 23:21:56 +0000

Looking at the schema.rb file inside a rails application is a great way to get a sense of the layout of the application. It's a nice one stop shop for finding out about the models and the attributes of those models that the application is modeled with, however sometimes it can still be a bit daunting to make sense of it all.

If only there was a way to see how everything was connected!

While there are schema design tools out there that allow you to write out the SQL to create and get a visual layout of the database schema, it requires you to write it all out by hand and more often than not it is in a slightly different syntax than actual SQL.

Remembering the syntax for languages is difficult enough, so why add yet another to the pile?

Just when it seems all hope is lost, a helping hand has come to the rescue!

dbdiagram has added in support for importing you rails schema and turning it into the required syntax for their program and thus printing out a beautiful representation of your applications database which can then be exported and shared with your team.

To make this happen simply visit dbdiagram, click the import button in the top of the window, select the import from Rails(schema.rb) option from the drop down:

This will open up a window in which the contents of the applications schema.rb file can be uploaded by clicking the upload schema.rb button in the top right of the window. You can then navigate to the location on your machine where the application lives and get to its schema.rb file and click open once you have the schema.rb selected. Once you click open you should see the contents of the applications schema file appear in dbdiagram's window:

Next, click the submit button at the bottom and then you will see the applications schema nicely laid out for you which can then be moved around the page by clicking and dragging the tables around to allow for even further readability:

Happy Rubying!

Redirecting users to their intended url via the session hash in rails after signing in.

Collin — Sun, 27 Dec 2020 18:13:03 +0000

As you have probably done before inside of a rails app, requiring users to be signed in before being able to access certain pages in the application is a pretty common task. Typically, you would have a method that runs as a before action inside of a controller.

So a user visits your app, tries to access say, their own profile page and since they didn't sign in first, the are kicked to the sign in page and hopefully politely told that they must sign in first. Pretty standard stuff here.

But depending on where you redirect the user to after they sign in, that my not align with where the user was trying to go to in the first place before being sent to the sign in screen.

Image this case, say you have a blogging application and a user visits the app, and immediately tries to edit a blog post they wrote, perhaps a friend pointed out a typo to them and they want to address the typo. So the user initially set out to land on a specific posts page so that they could then click an edit button to edit the post.

However, the user is redirected to the sign in screen as a result of a before action you have to require sign in. The user signs in successfully but is then routed to their profile page, which is not where the user originally wanted to go though. How can we provide a helping hand to the user so that we get them back to their original target of a specific posts page?

Our good friend the session hash is here to help us! We can modify our require sign in method to grab the intended url that the user was attempting to go to by using the request object that is passed along when a user navigates around the application. Then we can grab the url property out of the request object and store that inside the session hash for later use. So our require sign in method may look something like this:

  def require_signin
    unless current_user
      session[:intended_url] = request.url
      redirect_to new_session_url, alert: "Please sign in first!"
    end
  end

Here we are saying that unless there is a current user we want to store that url in the session hash and redirect the user to the sign in page.

Now after the user signs in we can use the :intended_url property of the session hash, if it's there to get the user back to where they originally wanted to go. That could look something like this:

    def create
        if user = User.authenticate(params[:email_or_username], params[:password])
            session[:user_id] = user.id
            flash[:notice] = "Welcome back, #{user.name}!"
            redirect_to(session[:intended_url] || user)
            session[:intended_url] = nil
        else
            flash.now[:alert] = "Invalid email/password combination!"
            render :new
        end
    end

There is a bit going on here but the important line is the fourth line inside the create action. What happens here is that after successfully being authenticated, the user will be redirected to their intended url if that property is set or instead they will be redirected to their profile page.

Mission accomplished!

Happy Rubying!!!

Ruby's Partition Method

Collin — Sun, 13 Dec 2020 23:00:40 +0000

Ruby's enumerable module is full of really delightful methods that can aid you in accomplishing a vast amount of tasks on collections. The focus of this post will be the partition instance method.

As a short detour before exploring the partition method, it's worth noting that in order to include the enumerable mixin within a class, whether it be a standard built in Ruby class or a class of your own, the class must first have an each method defined within the class. Only then can you include the enumerable mixin and gain access to all of the powerful methods that the module defines.

With that little factoid out of the way we can now look at the partition method.

From the official documentation, the partition method:

Returns two arrays, the first containing the elements of enum for which the block evaluates to true, the second containing the rest.

Time for a simple example.

2.6.3 :008 > nums = (1..25).to_a
 => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25] 

2.6.3 :009 > odd, even = nums.partition { |n| n.odd? }
 => [[1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25], [2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24]] 

# As provided by Emily Giurleo (see comment below), we can alternatively write the code above as follows:

odd, even = nums.partition(&:odd?)

# Pretty nice!!!

2.6.3 :010 > odd
 => [1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25] 

2.6.3 :011 > even
 => [2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24]

Pretty straight forward. On the first line we use Ruby's Range class to make a set of values that span from 1 to 25. We then call the to_a method on the range which places the range of values into an array. Next we declare two variables separated by a comma, each of which will receive one of the arrays which will be returned from the partition method. The first variable that is declared, in this case the odd variable, will reference the array that contains the values that evaluate to true based upon the logic within the block that is passed to the partition method. The second variable, even in this case, will reference the array of values which evaluate to false based upon the block passed to partition. We now have two completely new arrays containing the desired values based upon the logic in the block passed to partition. Important to note that the original nums array remains unchanged, the array is not mutated by sending the partition message to the nums variable.

Let's step things up some to perhaps a more practical example. Let's look at a use case that easily allows us to see what students passed and failed a certain subject. In this example we want to know which students passed and failed history. Using partition we can easily achieve this goal.

2.6.3 :006 > collin = {name: "Collin", grades: {history: "B", math: "A", science: "B"}}
 => {:name=>"Collin", :grades=>{:history=>"B", :math=>"A", :science=>"B"}}

2.6.3 :007 > uma = {name: "Uma", grades: {history: "A", math: "B", science: "A"}}
 => {:name=>"Uma", :grades=>{:history=>"A", :math=>"B", :science=>"A"}}

2.6.3 :008 > jordan = {name: "Jordan", grades: {history: "C", math: "B", science: "B"}}
 => {:name=>"Jordan", :grades=>{:history=>"C", :math=>"B", :science=>"B"}}

2.6.3 :009 > henry = {name: "Henry", grades: {history: "F", math: "B", science: "B"}}
 => {:name=>"Henry", :grades=>{:history=>"F", :math=>"B", :science=>"B"}}

2.6.3 :010 > students = [collin, uma, jordan, henry]
 => [{:name=>"Collin", :grades=>{:history=>"B", :math=>"A", :science=>"B"}}, {:name=>"Uma", :grades=>{:history=>"A", :math=>"B", :science=>"A"}}, {:name=>"Jordan", :grades=>{:history=>"C", :math=>"B", :science=>"B"}}, {:name=>"Henry", :grades=>{:history=>"F", :math=>"B", :science=>"B"}}]

2.6.3 :011 > passed_history, failed_history = students.partition { |student| student[:grades][:history] <= "D" }
 => [[{:name=>"Collin", :grades=>{:history=>"B", :math=>"A", :science=>"B"}}, {:name=>"Uma", :grades=>{:history=>"A", :math=>"B", :science=>"A"}}, {:name=>"Jordan", :grades=>{:history=>"C", :math=>"B", :science=>"B"}}], [{:name=>"Henry", :grades=>{:history=>"F", :math=>"B", :science=>"B"}}]]

2.6.3 :012 > passed_history
 => [{:name=>"Collin", :grades=>{:history=>"B", :math=>"A", :science=>"B"}}, {:name=>"Uma", :grades=>{:history=>"A", :math=>"B", :science=>"A"}}, {:name=>"Jordan", :grades=>{:history=>"C", :math=>"B", :science=>"B"}}] 

2.6.3 :013 > failed_history
 => [{:name=>"Henry", :grades=>{:history=>"F", :math=>"B", :science=>"B"}}]

I hope this gives you some ideas on how you can leverage the power Ruby's partition method to your advantage.

Happy Rubying!

Basic Enum usage for defining roles or statuses on models in Rails

Collin — Wed, 11 Nov 2020 17:55:48 +0000

Have you ever wanted to have a number of different options for the value of an attribute, say on a User model, such as an attribute called role that could be any of the following values:

admin, volunteer, customer, etc.

Perhaps you're working on a small version of Airbnb and you want the rental properties to have an availability status but you don't want it based in a boolean type attribute. There are plenty of gems that you could use to achieve this goal but let's explore something that comes with Rails out of the box.

Enter ActiveRecord::Enum. From the api docs:

Declare an enum attribute where the values map to integers in the database, but can be queried by name.

What this means is that you would define a column on the database table for the model that you are wanting to add roles or status options to that would be of type integer. Inside the model file for the model you would declare an enum and pass the options that you would like to have for the roles or statuses as an array of symbols.

NOTE - you can also explicitly map the attribute and the integer using a hash instead if desired.

The integers from the role column on the users database table are mapped to the index's of the array holding the attribute options.

The other nice thing here is that Enum provides you with a handful of dynamically defined methods for querying and updating an instances value for the attribute.

Let's generate a new rails app and play around with this feature to practice and see what kind of fun things we get for free.

rails new enum_practice
cd enum_practice/

Now let's generate a quick model and migration for a User model.

rails g model User name role:integer --no-test-framework

The above command will generate a user.rb file and a migration file to create the users table with the columns: name - which is of type string (the default type if no type is specified)
role - This will be the enum column and again it's of type integer

Let's look at the migration file we got from running the above command:

class CreateUsers < ActiveRecord::Migration[6.0]
  def change
    create_table :users do |t|
      t.string :name
      t.integer :role

      t.timestamps
    end
  end
end

If we want to have a default role set when a new user gets created we can pass that default option on the t.integer :role line. We will do this but first we need to decide what our initial list of roles will be for this model.

Let's say there are two roles we want on the user model for now: admin and volunteer.
To do this add this line to your user.rb file:

class User < ApplicationRecord
    enum role: [:volunteer, :admin]
end

Alternatively, you can write that line in a syntax that you will probably see more often out in the wild:

class User < ApplicationRecord
    enum role: %i(volunteer admin)
end

Both create an array of symbols.

We probably don't want every new user that gets created to be an admin so let's setup our migration so that the default role of all new users is :volunteer.

Looking at the migration file again, we are reminded that the column we want to set a default on is of type integer so our default value needs to be just that, an integer. What integer value do we want here? Well looking at our array of roles again we want :volunteer which is at index 0 of the enum role array. Let's add the line needed to set this default.

class CreateUsers < ActiveRecord::Migration[6.0]
  def change
    create_table :users do |t|
      t.string :name
      t.integer :role, default: 0

      t.timestamps
    end
  end
end

Let's run the migration and then hop into the rails console:

bin/rails db:migrate
bin/rails c

Ok, new user time!

user = User.new(name: "Collin")
 => #<User id: nil, name: "Collin", role: "volunteer", created_at: nil, updated_at: nil>

Looks like it's working! We only passed in a value for name when instantiating a new User object but since we setup a default for role that default value is assigned to our new instances role attribute.

Let's now explore some of the built in methods we get from using Enum.

We can send the object a message to find out what role it has:

user.role
 => "volunteer"

We can send the object a message to get a boolean value back based on whether or not the user is a volunteer:

user.volunteer?
 => true

Similarly we can send the object a message to find out if it is an admin:

user.admin?
 => false

This user has been a big help to the organization and deserves a promotion to admin status! Easy enough to do:

 user.admin!
   (0.1ms)  begin transaction
  User Create (0.7ms)  INSERT INTO "users" ("name", "role", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "Collin"], ["role", 1], ["created_at", "2020-11-11 17:09:53.227728"], ["updated_at", "2020-11-11 17:09:53.227728"]]
   (1.0ms)  commit transaction
 => true

Here we can see the SQL that was fired off, notice the role has been changed to reflect the integer 1. Did this actually update the role of our user? Let's send a message and find out!

user.admin?
 => true

Other ways to change the role for the user are:

user.role = "volunteer"
 => "volunteer" 
user.role
 => "volunteer"

and

user.role = :admin
 => :admin 
user.role
 => "admin"

An important thing to note with the above two ways though is that you will have to call save after updating the role in order to persist the change

Now let's take a look at some query methods for getting either all admins or all volunteers. First let's create four new User instances:

names = %w(Uma Jordan Henry Collin)
names.each {|name| User.create(name: name)}

Now let's change the first two users to be admins:

two_users = User.limit(2)
two_users.each {|user| user.admin!}

Now we have two admin users and two volunteer users in the database. Let's get all the admin users:

User.admin
  User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."role" = ? LIMIT ?  [["role", 1], ["LIMIT", 11]]
 => #<ActiveRecord::Relation [#<User id: 2, name: "Uma", role: "admin", created_at: "2020-11-11 17:17:46", updated_at: "2020-11-11 17:25:50">, #<User id: 3, name: "Jordan", role: "admin", created_at: "2020-11-11 17:17:46", updated_at: "2020-11-11 17:25:50">]>

What about all the volunteers?

User.volunteer
  User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."role" = ? LIMIT ?  [["role", 0], ["LIMIT", 11]]
 => #<ActiveRecord::Relation [#<User id: 4, name: "Henry", role: "volunteer", created_at: "2020-11-11 17:17:46", updated_at: "2020-11-11 17:17:46">, #<User id: 5, name: "Collin", role: "volunteer", created_at: "2020-11-11 17:17:46", updated_at: "2020-11-11 17:17:46">]>

So by calling one of the role options on the User class itself we can get back an array of all the instances that match the role message we send to User. Pretty cool!

We can also quickly send another message to the User class to find out what all the role options are and the corresponding integer values with:

User.roles
 => {"volunteer"=>0, "admin"=>1}

Simply pluralize the name of the column and send that message to the class. We named the column role so we simply pluralized it( roles ) and sent that message to the User class (User.roles) and got back the hash of options and their integer values. Nifty indeed!

As a final note, using enum makes it incredibly easy to define new options on the model. Simply add the new option(s) to the end of the enum role: [:volunteer, :admin] array and that's it! The new options will be mapped to the next integer values.
Example:

class User < ApplicationRecord
    enum role: [:volunteer, :admin, :vendor, :customer]
end

User.roles
 => {"volunteer"=>0, "admin"=>1, "vendor"=>2, "customer"=>3}

or in the alternate syntax style:

class User < ApplicationRecord
    enum role: %i(volunteer admin vendor customer)
end

User.roles
 => {"volunteer"=>0, "admin"=>1, "vendor"=>2, "customer"=>3}

Happy Rubying!