In Ruby 3.2, a new class Data was introduced as a way to define simple immutable value objects. A value object is a type of object that represents a value in a program, such as a point in 2D space or a date. The main advantage of value objects is that they are easy to understand, simple to use, and can improve the readability and maintainability of code. The proposal to add Data class was accepted by Matz on the Ruby forum here. How does it work?Using the newly defined class Data we can create a simple immutable

Rails provides the has_secure_password method, which makes it gloriously easy to implement authentication in our application. But we often need an extra layer of verification before allowing users to update certain fields. For e.g. Users must provide their “old” password when updating their email/password fields. Before Rails 7.1To implement this, we must manually add and validate the current_password accessor: # app/models/user.rb class User < ActiveRecord::Base has_secure_password attr_accessor :current_password end# app/controllers/passwords_controller.rb class PasswordsController < ApplicationController def update password_challenge = password_params.delete(:current_password)

Rails 7.1 adds the --parent option using which we can create a job that inherits from the superclass. Let's learn how to use it.

Turbo provides the most basic building blocks for building Hotwire application. In this article, let's learn more about its features.

Rails framework is famous for developers' happiness and making things simpler due to its magic, provided developers follow proper conventions. To extend this magic and to make things simple further, Rails 7 has introduced a change with this PR after which, inverse_of would be inferred automatically for model associations having scopes. In this article, we'll dive into understanding it with examples. Let's say we have a Project model with many assigned tasks. # app/models/project.rb class Project < ActiveRecord::Base has_many :tasks, -> { assigned } end # app/models/task.rb class Task < ActiveRecord::Base belongs_to

We often come across use cases in a Rails application where we need to create, update, or delete records in bulk. Most ORMs naively update or insert each record individually by executing N+1 database queries. To address this problem, Rails 6 added the upsert_all method that provides a faster way to update and insert a large number of records. upsert_all uses a single SQL INSERT statement for updating/inserting the records. And it does so without instantiating any models. Nor does it trigger any Active Record callbacks or validations ! How upsert_all works? If we check the

In Rails, multiple scopes can be created and chained together. What if we wish to apply a specific scope to a group of queries? Consider the following scenario: we have Post and Comment models and we want to perform few operations on public posts. # app/models/post.rb class Post < ActiveRecord::Base scope :public, -> { where(private: false) } endLoading development environment (Rails 7.0.0.alpha2) 3.0.0 :001 > Post.public.update_all(body: 'public post') Post Update All (4.1ms) UPDATE "posts" SET "body" = ? WHERE "posts"."private" = ? [["body", "public post"], ["private", 0]] 3.0.0

Rails 7 adds the partial_inserts config to config.active_record that is used to control partial writes when creating a new record. config.active_record.partial_inserts is a boolean value and controls whether or not partial writes are used when creating new records (i.e. whether inserts only set attributes that are different from the default). Configuring config.active_record.partial_inserts In a newly created Rails 7.0 application, config.load_defaults 7.0 is set by default in application.rb. The default value of partial_inserts for config.load_defaults 7.0 is false and for

Rails 7 is introducing a new method invert_where that will invert all scope conditions. It allows us to invert an entire where clause instead of manually applying conditions. We can either chain invert_where to a scope or to a where condition. class Account scope :active, -> { where(active: true) } end Account.active.invert_where => "SELECT \"accounts\".* FROM \"accounts\" WHERE \"accounts\".\"active\" != 1"Account.where(active: true).invert_where => "SELECT \"accounts\".* FROM \"accounts\" WHERE \"accounts\".\"active\" != 1"What are the various side effects of using invert_where?1. The invert_where method inverts all the where

If you're hosting your web server in a particular region, it might be necessary to comply with the GDPR norms of that region. Anonymizing and encrypting data becomes necessary in such situations. In this blog, we will discuss the attribute encryption that Rails 7 provides right out of the box. And we will also see the Deterministic & Non Deterministic approaches. (If you're using Rails version lesser than 7, check out our previous blog here on how to write a custom encryption framework.) ActiveRecord attribute encryption in Ruby on Rails for better securityIn this blog post, we will explore a