Rails ActiveRecord count, size and length, map and pluck

Dario Chuquilla — Fri, 15 Mar 2024 03:33:51 +0000

Here I want to share with you some best practices for daily query requirements to help you improve the server's memory usage. We’ll discuss when to use each method and how they can help optimize memory usage and database calls.

Count and Size and length

All of these are used to get the number of records retrieved by the query.

Count

It returns the number of records by performing a query to the database every time it is called. I think it is pretty useful in asynchronous executions to bet the latest count of queries.

users = User.all
# SELECT "users".* FROM "users"
users.count
# SELECT COUNT(*) FROM users

Size

This is a bit smarter, it calls to count in the database when records are not loaded in memory yet.

users = User.all
# SELECT "users".* FROM "users"
users.size
# No query needed, returns the number of records in memory
User.all.size
# SELECT COUNT(*) FROM users

Length

This always gets from memory, It’s similar to size method, but it always loads the records.

users = User.all
# SELECT "users".* FROM "users"
users.length
# No query needed, returns the number of records in memory
User.all.length
SELECT "users".* FROM "users"

A small recap

You will see how size and length queries to database.

User.all.size
# SELECT COUNT(*) FROM users
# Performs COUNT and saves that number into memory

User.all.length
SELECT "users".* FROM "users"
# Performs a full scan query, load that result into memory, and then gets the length of that array.

Map and Pluck

To get an array of certain fields of query results.

Map

This method performs over the array of results of query and it only works with one field at a time, for more fields, you can pass a bloq as an argument, but first, it will load all fields of all records in memory.

User.all.map(&:id)
# SELECT "users".* FROM "users"
# [1, 2, 3, ...]

Pluck

This is a more efficient method than map, it performs a query with the specific field you want to get, so It consumes less memory and traffic with DB.

User.pluck(:id, :first_name)
# SELECT "users"."id", "users"."first_name" FROM "users"
# [[1, "name 001"], [2, "name 002"], [3, "name 003"], ...]

Conclusion

All of these methods are useful for all our requirements, sometimes it's better to load all info in memory at the beginning of the whole process (in tables with a small number of records), and it is necessary to control what you get from DB mostly in tables with a huge number of records.

For counting I prefer to use size to not call DB every time I need the number of records in a simple request flow. For a small number of fields 'pluck' is your friend.

Remember, optimizing database calls and memory usage is crucial for maintaining a fast, responsive Rails application. Always consider the trade-offs when choosing which ActiveRecord method to use.

I hope this helps! Let me know if you need any further assistance.

Ruby Attributes VS Instance variables

Dario Chuquilla — Mon, 04 Mar 2024 02:02:52 +0000

I am finally going to clarify the confusion among developers about the use of attributes and instance variables in Ruby classes. In this article, I will show you the similarities and differences between these two concepts and provide best practices for using them.

First things first SIMILARITIES

Attributes and instance variables are used to store data within a class.
They can both be accessed and modified within the class.

Now the differences

Attributes have a wider scope than instance variables.
Attributes can be accessed and modified outside the class using accessors, while instance variables are only accessible within the class.
Attributes can be defined with specific data types, ensuring data integrity. Instance variables, on the other hand, can hold any data type.
Attributes can be initialized during declaration, while instance variables need to be initialized within the class.
Instance variables consume more memory than attributes since they are not bound to a specific data type.

Best practices

attr_accessor is so versatile, that it lets us to store a value anywhere.

class AttributesInstances
  attr_accessor :my_attribute

  def initialize
    @my_attribute = "Hello" # instance variable used to store the value of the attribute
  end

  def show_me
    puts @my_attribute # instance variable used to access the value of the attribute
    puts self.my_attribute # attribute reader used to access the value of the attribute
  end
end

ai = AttributesInstances.new
ai.show_me
#=> Hello
#=> Hello

As you can see, it is possible to access the attribute value by the instance variable used to store it during the initialization.

class AttributesInstances
  attr_accessor :my_attribute

  def initialize
    self.my_attribute = "Hello" # attribute writer used to set the value of the attribute
  end

  def show_me
    puts @my_attribute # instance variable used to access the value of the attribute
    puts self.my_attribute # attribute reader used to access the value of the attribute
  end
end

ai = AttributesInstances.new
ai.show_me
#=> Hello
#=> Hello

In this case, the value can be stored with self which is the attribute writer method.

attr_reader and attr_writer It has their special treatment.

class AttributesInstances
  attr_reader :my_attribute_reader

  def initialize
    # self.my_attribute_reader = 'Hello' # RISES NoMethodError: undefined method `my_attribute_reader=' for #<AttributesInstances:0x00007f8f3b8b3e40>
    @my_attribute_reader = 'Hello' # instance variable used to set the value of the attribute
  end

  def show_me
    puts @my_attribute_reader # instance variable used to access the value of the attribute
    puts self.my_attribute_reader # attribute reader used to access the value of the attribute
  end
end

ai = AttributesInstances.new
ai.show_me
#=> Hello
#=> Hello

Here, the value can only be stored by an instance variable, when self is used, it raises the undefined method exception.

I hope this is useful for getting your code cleaner and better organized.

Any comments are fully welcomed.

DEV Community: Dario Chuquilla