soniya.rayabagi
Fri May 24 2024
How to schedule tasks using cron expressions in GitHub Actions:
By defining a cron schedule in the workflow YAML file, we can automate the execution of tasks at specific intervals.
For instance, setting */5 * * * *
in the cron expression triggers the workflow every 5 minutes.
Monitoring workflow runs in the "Actions" tab of the GitHub repository allows to verify that the scheduled tasks are executing as intended.
#cronjobs #workflowautomation
mahesh.bhosle
Fri May 24 2024
When terraform state file is locked and you are unable to acquire a state lock, you can use terraform force-unlock <LOCK_ID>
to forcefully remove the lock.
#terrafrom
vaibhav.yadav
Thu May 23 2024
Use git reset --mixed HEAD~1
command to undo your last commit without losing the changes made in your last commit.
#git #gitReset #github
adithya.hebbar
Thu May 23 2024
In TypeScript interfaces, ?:
denotes optional properties. Here's an example:
interface User {
name: string;
age?: number; // Optional
}
const user1: User = { name: "Joe Mama" }; // Age is optional
const user2: User = { name: "Tony", age: 30 };
console.log(user1); // Output: { name: "Joe Mama" }
console.log(user2); // Output: { name: "Tony", age: 30 }
#javascript #typescript
adithya.hebbar
Thu May 23 2024
Utility Types:
TypeScript's Utility Types simplify complex type manipulations. For instance, Partial<T>
makes all properties of type T optional
interface User {
id: number;
name: string;
email: string;
}
function displayUser(user: Partial<User>) {
console.log(user);
}
displayuser({ name: "Joe Mama" }); // Partial<T> will make the properties optional hence this is valid
#javascript #typescript
ayushsrivastava
Thu May 23 2024
EAGER LOADING
Eager loading in Rails is a technique used to optimize database queries by loading associated records of the objects returned by the query, thereby reducing the number of database calls. This is particularly useful when you have associations defined in your models and you want to avoid the "N+1 query problem."
What is the N+1 Query Problem?
“N+1 Queries” are a very common cause of repeated queries in Rails applications. This happens when you make a request for a single row in one table, and then make an additional request per element in a has_many
relationship, usually in a loop.
Here’s an example:
Consider two models: Author
and Book
, where an Author
has many Books
.
class Author < ApplicationRecord
has_many :books
end
class Book < ApplicationRecord
belongs_to :author
end
Scenario Without Eager Loading When you fetch authors and then access their books, Rails performs an additional query for each author to get their books.
# Fetching all authors and their books
authors = Author.all
authors.each do |author|
puts author.books.pluck(:title)
end
This will result in one query to fetch the authors and multiple queries to fetch books for each author, leading to the N+1 query problem.
How Eager Loading Works
Eager loading addresses this problem by loading all the necessary data in as few queries as possible, usually through the use of includes
, eager_load
, or preload
.
Using Eager Loading with includes
To avoid the N+1 query problem, you can use includes
to preload the associated books when fetching authors.
# Fetching all authors and their books with eager loading
authors = Author.includes(:books)
authors.each do |author|
puts author.books.pluck(:title)
end
With includes
, Rails performs a single query to fetch all authors and another single query to fetch all associated books.
Using Eager Loading with eager_load
eager_load
forces Rails to use a SQL JOIN
to load the associated records. This can be useful if you need to filter or sort based on the associated records.
# Fetching all authors and their books with eager loading using JOIN
authors = Author.eager_load(:books)
authors.each do |author|
puts author.books.pluck(:title)
end
This approach performs a single query with a LEFT OUTER JOIN
.
Using Eager Loading with preload
preload
is similar to includes
, but it always uses separate queries for loading the associations.
# Fetching all authors and their books with eager loading using separate queries
authors = Author.preload(:books)
authors.each do |author|
puts author.books.pluck(:title)
end
preload
is useful when you know that separate queries will be more efficient, for example, when fetching a large number of records.
Summary
Eager loading is a powerful tool in Rails that helps to optimize database access by pre-loading associations. Using includes
, eager_load
, or preload
appropriately can significantly improve the performance of your application by reducing the number of database queries.
#rails #db #optimizing_queries
ayushsrivastava
Tue May 21 2024
Scoped Associations with Joins
Let's consider the following models:
• Author
with attributes id
, name
• Book
with attributes id
, title
, published
, author_id
The association is that an Author
has many Books
, and a Book
belongs to an Author
.
Defining Scoped Associations
First, let's define a scope on the Book
model to filter only published books:
class Book < ApplicationRecord
belongs_to :author
scope :published, -> { where(published: true) }
end
Next, let's use this scope in the Author
model to create a scoped association:
class Author < ApplicationRecord
has_many :books
has_many :published_books, -> { published }, class_name: 'Book'
end
Now, Author
has an association called published_books
, which only includes books that are published.
Using Scoped Associations with Joins
We can now use the scoped association in joins to fetch authors and their published books. Example 1: Fetch Authors with Published Books To fetch authors along with their published books:
@authors_with_published_books = Author.joins(:published_books).select('authors.*, books.title as book_title')
This query joins the authors
table with the books
table but only includes books that are published, thanks to the scoped association published_books
.
As a result, each Author
object in @authors_with_published_books
will have:
• All attributes of the Author
model.
• An additional attribute called book_title
representing the title of each associated book.
#rails #scoped_associations_with_joins
ayushsrivastava
Tue May 21 2024
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
giritharan
Mon May 20 2024
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
soniya.rayabagi
Mon May 20 2024
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
Showing 5 to 7 of 65 results