Fueling Curiosity, One Insight at a Time

Scoped associations

Let's say we have two models: User and Post. And we want to get all posts for user. We can do this:

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :user
end

user = User.first
user.posts

But what if we don't ever want to include posts for user which are published? Often I see people doing this:

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :user

  scope :published, -> { where(published: true) }
end

user = User.first
user.posts.published

And this is fine, but you can somehow forget to add published scope to your query. And then you will get all posts, even unpublished. And this is not what you want. Some people use default_scope for this, but it is not good idea. So what we can do? We can use scope in association:

class User < ActiveRecord::Base
  has_many :posts, -> { published }
  has_many :not_published_posts, -> { not_published }
end

class Post < ActiveRecord::Base
  belongs_to :user

  scope :published, -> { where(published: true) }
  scope :not_published, -> { where(published: false) }
end

user = User.first
user.posts # only published posts here

#rails #database #model #associations

There are two ways to call respond_to: Either we can pass it as a list of symbols or pass a block
Block Version:

def index
  @people = Person.all

  respond_to do |format|
    format.json { render json: @people}
    format.xml { render xml: @people }
    format.html { render :index}
  end
end

Symbol version:

def index
  @people = Person.all
  respond_to :json, :xml, :html  
end

#respondto #actionview #rails

kubectl rollout restart deployment <deployment-name> command used to restart pods managed by a Kubernetes deployment without making any modifications to the deployment configuration.
#devops #Kubernetes #rollingrestart

Active Record is the Object-Relational Mapping (ORM) layer provided by Ruby on Rails. It facilitates the interaction between Ruby objects and a relational database. It helps us interact with our database using Ruby instead of writing SQL queries directly.

Key features of ActiveRecord include:

• Model Definition: ActiveRecord allows developers to define models that represent database tables. These models inherit from the ActiveRecord::Base class and include methods for defining associations, validations, and callbacks.
• CRUD Operations: ActiveRecord provides methods for performing CRUD (Create, Read, Update, Delete) operations on database records. These methods allow developers to manipulate records using Ruby syntax without writing explicit SQL queries.
• Associations: ActiveRecord simplifies the definition and management of associations between models. It supports various types of associations, including belongs_to, has_many, has_one, and has_and_belongs_to_many, allowing us to express complex relationships between database tables.
• Validations: ActiveRecord includes a robust validation framework for ensuring data integrity. We can define validation rules such as presence, uniqueness, length, format, and custom validations to enforce data constraints at the model level.
#orm #rails

What is happening behind the scenes after we configured database credentials in database.yml
• Conduct the three-way handshake to establish a TCP connection to the server.
• Exchange preferences and requirements with the database software to establish the session parameters.
• Perform database authentication checks to establish the client's identity.
• PostgreSQL supports several authentication methods, such as passwords (plaintext or MD5),GSSAPI, SSPI, and more.
• The client (Rails, via ActiveRecord) can now send commands to the server. Commands are typically SQL statements. These statements are sent as simple text strings in the 'Query' message format.
How Number of connection affects the database server
• When the number of connections or pools to a server increases, CPU usage will rise. This increased demand for memory and CPU resources can affect other operations, such as transaction speeds. Managing many connections can also reduce the effectiveness of the database and decreasing overall system performance.
What will happen if we give more connections then we configured in PSQL?
• When that limit of a db is reached, additional connection requests are rejected.
How connections b/w rails and PSQL established and maintained?
• Connection pooling is a technique where database connections are reused for multiple requests instead of being closed after each query. This approach uses a connection pooler, a software that manages the connections between the database and its client applications, optimizing the use of resources and improving performance.
• Establishing the connections is a fairly long operation.
• Connection pooler is sitting b/w client and server. client connects to the connection pooler instead of directly to the database. Req is sent to pooler and the pooler interprets queries returns back the response from DB.
• Once the response is returned it closes the connection. But the thing here is opening and closing connection is not overhead comparatively with client and DB connections.
#orm #activerecord #psql #rails

Dup vs clone while dealing with Active Record:
• Dup creates a new record with a blank ID, which will create a new object on the database with a new ID after hitting .save.

user = User.first
user1 = user.dup
user1:
<User id: nil, name: "Rails"> 

• clone creates a new record with the same ID, after hitting save on the clone object this will overwrite the existing data.

user = User.first
user1 = user.clone
<User id: 1, name: "Rails"> 

• If you change some value on the above attribute and put .save it will overwrite the original obj.
#dupvsclone #ruby #rails

In Rails, the resources method provides a convenient way to define RESTful routes for our application's resources. Instead of manually specifying separate routes for each CRUD action (Create, Read, Update, Delete), we can use the resources method to define all these routes with a single line of code.

# config/routes.rb

Rails.application.routes.draw do
  resources :students
end

With this single line of code, Rails automatically generates the following RESTful routes for the students resource:

GET     /students          # Index action (display a list of students)
GET     /students/new      # New action (display a form to create a new student)
POST    /students          # Create action (create a new student)
GET     /students/:id      # Show action (display details of a specific student)
GET     /students/:id/edit # Edit action (display a form to edit a specific student)
PATCH   /students/:id      # Update action (update a specific student)
PUT     /students/:id      # Update action (update a specific student)
DELETE  /students/:id      # Destroy action (delete a specific student)

#rails #routes

In a Rails application, the seeds.rb file is used to populate the database with initial data. This file typically resides in the db directory of our Rails application. The data added through the seeds.rb file is often used for testing or for providing initial data in a fresh installation of the application.

After defining the data in the seeds.rb file, we can populate the database by running the rails db:seed
#rails #database

Generic Classes:

• To ensure that the function correctly infers the type of the argument passed to it and returns the same type, you can use TypeScript's generic type notation

function identityType<Type>(prop: Type): Type {
  return prop;
}
identityType(1);

• If we plan to use generic <> have to add, it tells ts compiler as the function in generic fn.
• From the above code we can see the example, if we planned to use string we can or boolean we can. The thing is both prop and return type has to be similar
#typescript #javascript

Difference between any and unkown type in ts
any:
- The any type is a dynamic type, variables of type any can hold values of any data type, and TypeScript type checking is effectively turned off for them.
- While any provides flexibility, it bypasses TypeScript's type checking entirely, which can lead to loss of type safety and potentially introduce bugs.

unknown:
- The unknown type is a type-safe counterpart of any. It represents values of an unknown type.
- Variables of type unknown can hold values of any type, but you cannot perform operations on them without first narrowing their type or asserting a more specific type.

Both any and unknown provide flexibility in handling values of unknown types, any completely disables type checking, while unknown enforces type safety by requiring you to explicitly narrow the type before performing operations on the value. It's generally recommended to prefer unknown over any when dealing with values of unknown types, as it helps maintain type safety in your TypeScript code.

#typescipt #javascipt