DEV Community: Santhosh_M

CURSORS AND TRIGGERS

Santhosh_M — Wed, 01 Oct 2025 05:53:25 +0000

Simulating Cursors and Using Triggers in SQL

Cursors and triggers are powerful tools in SQL we’ll explore both with practical examples.

1️⃣ Employee Table Setup

Let’s create an Employee table with sample data:

CREATE TABLE Employee (
    emp_id INTEGER PRIMARY KEY,
    name TEXT,
    salary INTEGER
);

INSERT INTO Employee(emp_id, name, salary) VALUES
(1, 'Alice', 60000),
(2, 'Bob', 45000),
(3, 'Charlie', 75000),
(4, 'David', 50000);

2️⃣ Simulating a Cursor in Programiz

In traditional SQL, cursors allow row-by-row processing. Since Programiz doesn’t support cursors, we can use a SELECT statement with a condition to get the same result.

SELECT name 
FROM Employee 
WHERE salary > 50000;

Output:

Alice
Charlie

This effectively simulates a cursor that processes only employees with salary greater than 50,000.

3️⃣ Trigger Example: AFTER INSERT

Triggers automatically execute actions in response to table events.

Scenario

Whenever a new student is added to the Students table, we want to log the registration in a Student_Audit table.

CREATE TABLE Students (
    student_id INTEGER PRIMARY KEY,
    name TEXT,
    dept TEXT
);

CREATE TABLE Student_Audit (
    audit_id INTEGER PRIMARY KEY AUTOINCREMENT,
    student_id INTEGER,
    action TEXT,
    action_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

AFTER INSERT Trigger

SQLite supports triggers like this:

CREATE TRIGGER after_student_insert
AFTER INSERT ON Students
BEGIN
    INSERT INTO Student_Audit(student_id, action)
    VALUES (NEW.student_id, 'Student Registered');
END;

Test the Trigger

INSERT INTO Students(student_id, name, dept)
VALUES (1, 'Alice', 'CSBS');

SELECT * FROM Student_Audit;

Output:

audit_id	student_id	action	action_time
1	1	Student Registered	2025-10-01 09:00:00

The trigger automatically logs the registration — no manual step needed.

4️⃣ Key Takeaways

Feature	How to Use in Programiz / SQLite
Cursor	Use `SELECT ... WHERE` for conditional row processing.
Trigger	Automate actions on INSERT, UPDATE, DELETE.

Even without traditional cursors, you can process data row-wise using conditions. Triggers help maintain audit logs or automatic actions.

Conclusion

By simulating cursors and using triggers, you can:

Filter and process rows based on conditions.
Automatically respond to database events like inserts.

This makes your database smarter and more automated, even in **SQLite-based editors

Tip: For more advanced row-by-row processing, you can combine SQLite queries with application code (Python, Java, etc.) to simulate full cursor behavior.

TRANSACTIONS , DEADLOCKS AND LOG BASED RECOVERY

Santhosh_M — Wed, 01 Oct 2025 04:29:02 +0000

Transactions, Deadlocks & Log-Based Recovery in SQL: A Practical Guide

Databases must ensure data integrity and reliability even under concurrent access, system crashes, or unexpected failures. Three critical concepts that make this possible are transactions, deadlocks, and log-based recovery.

In this post, we’ll explore these with practical SQL examples using a simple Accounts table.

1️⃣ Setting Up the Accounts Table

Let’s start by creating a sample table:

CREATE TABLE Accounts (
    acc_no INT PRIMARY KEY,
    name VARCHAR(50),
    balance INT
);

INSERT INTO Accounts VALUES
(1, 'Alice', 1000),
(2, 'Bob', 1500),
(3, 'Charlie', 2000);

This simple table will help us demonstrate atomic transactions, deadlocks, and logging.

2️⃣ Transactions – Atomicity & Rollback

A transaction is a sequence of operations that must either complete entirely or not at all.

Example: transferring 500 from Alice to Bob, then rolling back:

BEGIN TRANSACTION;

-- Deduct from Alice
UPDATE Accounts SET balance = balance - 500 WHERE acc_no = 1;

-- Add to Bob
UPDATE Accounts SET balance = balance + 500 WHERE acc_no = 2;

-- Rollback transaction
ROLLBACK;

-- Verify balances
SELECT * FROM Accounts;

Result: No partial update occurs; balances remain unchanged.
This demonstrates atomicity.

3️⃣ Deadlock Simulation

A deadlock happens when two transactions block each other by waiting for locks on resources.

You need two separate database sessions to simulate:

Session 1

BEGIN TRANSACTION;
UPDATE Accounts SET balance = balance - 100 WHERE acc_no = 1; -- locks Alice
UPDATE Accounts SET balance = balance + 100 WHERE acc_no = 2; -- waits for Bob

Session 2

BEGIN TRANSACTION;
UPDATE Accounts SET balance = balance - 200 WHERE acc_no = 2; -- locks Bob
UPDATE Accounts SET balance = balance + 200 WHERE acc_no = 1; -- waits for Alice

Expected: The database detects a deadlock and aborts one transaction, preventing indefinite blocking.

4️⃣ Log-Based Recovery

Databases maintain logs to undo or redo changes in case of crashes. Most modern databases use:

MySQL (InnoDB) → undo logs and binary logs
PostgreSQL → Write-Ahead Logging (WAL)

Example:

BEGIN TRANSACTION;

UPDATE Accounts SET balance = balance + 500 WHERE acc_no = 3;

ROLLBACK;

The change is recorded in the log.
Rollback ensures the balance of Charlie remains 2000, even if the system crashes.
Logs can be inspected to verify undo/redo operations.

5️⃣ Key Takeaways

Concept	Description
Atomicity	Transactions are all-or-nothing; rollback cancels partial changes.
Deadlock	Occurs when transactions wait for each other’s locks; DB resolves automatically.
Log-Based Recovery	Logs allow recovery to a consistent state after crashes or rollbacks.

Conclusion

Understanding transactions, deadlocks, and logging is critical for building reliable, robust database applications.

Transactions ensure consistency even if operations fail.
Deadlocks are detected and resolved by the database engine.
Logs provide durability and recovery mechanisms.

Tip for Developers:
Test deadlocks safely using two database sessions and simulate transactions with rollback to see ACID properties in action.

INDEXING, HASHING AND QUERY OPTIMIZATION

Santhosh_M — Wed, 01 Oct 2025 04:16:59 +0000

Indexing, Hashing & Query Optimization in SQL: A Practical Guide

As databases grow, queries on large tables can become slow. Indexing is one of the most effective ways to improve performance. In this blog, we’ll explore B-Tree, B+ Tree, and hash-like indexing, and see how they optimize SQL queries with a practical example.

Setting Up the Students Table

We’ll use a Students table with 20 sample records:

CREATE TABLE Students (
    roll_no INT PRIMARY KEY,
    name VARCHAR(50),
    dept VARCHAR(20),
    cgpa DECIMAL(3,2)
);

INSERT INTO Students (roll_no, name, dept, cgpa) VALUES
(101, 'Alice', 'CSBS', 9.2),
(102, 'Bob', 'CSBS', 7.8),
(103, 'Charlie', 'ECE', 8.1),
(104, 'David', 'MECH', 6.9),
(105, 'Eva', 'CSBS', 8.5),
(106, 'Frank', 'ECE', 7.5),
(107, 'Grace', 'MECH', 9.0),
(108, 'Hannah', 'CSBS', 8.8),
(109, 'Ian', 'ECE', 7.2),
(110, 'Jack', 'CSBS', 9.1),
(111, 'Kate', 'MECH', 8.0),
(112, 'Leo', 'ECE', 8.3),
(113, 'Mona', 'CSBS', 7.9),
(114, 'Nate', 'MECH', 6.8),
(115, 'Olivia', 'ECE', 9.0),
(116, 'Paul', 'CSBS', 8.6),
(117, 'Quinn', 'MECH', 7.5),
(118, 'Rita', 'ECE', 8.4),
(119, 'Steve', 'CSBS', 9.3),
(120, 'Tina', 'MECH', 8.1);

B-Tree Index on roll_no

B-Tree indexes are ideal for exact matches and small-range queries:

CREATE INDEX idx_roll_no ON Students (roll_no);

SELECT * FROM Students WHERE roll_no = 110;

The database uses the index to quickly locate the student without scanning the entire table.

B+ Tree (Ordered B-Tree) on cgpa

B+ Tree indexes are excellent for range queries:

CREATE INDEX idx_cgpa ON Students (cgpa);

SELECT * FROM Students WHERE cgpa > 8.0;

Using the index, the database scans only relevant rows, improving query speed.

Index on dept for Exact Matches

While hash indexes are supported in some databases (like PostgreSQL), SQLite and most online editors use B-Tree indexes, which are still effective for equality checks:

CREATE INDEX idx_dept ON Students (dept);

SELECT * FROM Students WHERE dept = 'CSBS';

Indexing dept speeds up exact-match queries for departments.

Indexing Benefits at a Glance

Index Type	Column	Best Use Case
B-Tree	roll_no	Exact matches & small ranges
B+ Tree	cgpa	Range queries (`>`, `<`, `BETWEEN`)
B-Tree	dept	Exact-match queries (`=`)

⚠️ Note: Indexes consume storage and may slow INSERT/UPDATE. Use them wisely.

Query Optimization Tips
Index frequently used columns in WHERE, JOIN, ORDER BY clauses.
Avoid functions on indexed columns (e.g., UPPER(name)) as they may bypass indexes.
Use EXPLAIN to see if a query is using an index:

EXPLAIN SELECT * FROM Students WHERE cgpa > 8.0;

Choose the right index type:

Range queries → B+ Tree
Exact matches → Hash or B-Tree

Conclusion

Indexing is a powerful tool to speed up SQL queries and improve application performance. By using B-Tree, B+ Tree, and hash-like indexes, you can optimize searches, range queries, and exact-match lookups efficiently.

Try it yourself: create indexes, run queries, and see the difference in query execution!

ACID PROPERTY

Santhosh_M — Wed, 01 Oct 2025 04:05:45 +0000

ACID is a set of properties that guarantee reliability and consistency in database transactions. Whether you’re working with MySQL, PostgreSQL, or SQLite, understanding ACID is crucial for designing safe and robust applications.

Let’s break down ACID and see how it works in practice.

What is ACID?

ACID stands for:

Atomicity – A transaction is all-or-nothing. Either every step succeeds, or none does.
Consistency – Transactions always leave the database in a valid state.
Isolation – Transactions run independently without interfering with each other.
Durability– Once a transaction is committed, the data persists even if the system crashes.

Setup: Sample Accounts Table

CREATE TABLE Accounts (
    acc_no INTEGER PRIMARY KEY,
    name TEXT,
    balance INTEGER CHECK (balance >= 0)
);

INSERT INTO Accounts (acc_no, name, balance) VALUES
(1, 'Alice', 5000),
(2, 'Bob', 3000),
(3, 'Charlie', 2000);

Here, the CHECK (balance >= 0) ensures no negative balances, which helps demonstrate consistency.

Atomicity

A money transfer should be all-or-nothing. Let’s try transferring 1000 from Alice to Bob:

BEGIN TRANSACTION;

UPDATE Accounts SET balance = balance - 1000 WHERE acc_no = 1;
UPDATE Accounts SET balance = balance + 1000 WHERE acc_no = 2;

ROLLBACK;  -- Undo the transaction

Result: balances remain unchanged.
This shows that partial updates do not occur, ensuring atomicity.

Consistency

The database should always stay valid. For example:

INSERT INTO Accounts (acc_no, name, balance) VALUES (4, 'David', -500);

This fails due to the CHECK constraint, demonstrating that invalid data cannot enter the system.

Isolation

Two transactions running concurrently should not interfere.

Session 1:

BEGIN TRANSACTION;
UPDATE Accounts SET balance = balance - 500 WHERE acc_no = 1;
-- Do NOT commit yet

Session 2 (simultaneous):

SELECT * FROM Accounts WHERE acc_no = 1;

Depending on the isolation level, Session 2 may or may not see the uncommitted changes from Session 1.
This ensures transactions run independently.

Durability

Once a transaction is committed, it persists:

BEGIN TRANSACTION;
UPDATE Accounts SET balance = balance + 2000 WHERE acc_no = 3;
COMMIT;

Even if the database crashes or restarts, the update remains. This is durability in action.

Notes for SQLite Users

If you’re using Programiz or an online SQLite editor, some features like BEGIN TRANSACTION or COMMIT may not work due to automatic transaction management. In that case:

Run statements sequentially to observe effects.
Use local SQLite installations (CLI or DB Browser) to test transactions fully.

Conclusion

ACID properties are essential for safe and reliable databases. Understanding and testing them with practical SQL examples prepares you for real-world applications like banking systems, e-commerce, and more.

Try it yourself:
Experiment with transfers, constraints, and concurrent sessions to see ACID in action. It’s one of the best ways to really understand database reliability.

NORMALIZATION

Santhosh_M — Wed, 01 Oct 2025 03:26:25 +0000

Understanding 1NF, 2NF & 3NF with SQL (A Student–Course Example)

“Why do we even normalize databases? ”
If you’ve ever asked this question, you’re not alone.
Let’s take a fun ride into 1NF → 2NF → 3NF using SQL code and a real-world classroom scenario.

The Story: Students, Courses & Instructors

Imagine you’re designing a system to track which student is taking which course, and who teaches it.
Here’s the initial table we came up with:

StudentID	StudentName	CourseID	CourseName	Instructor	InstructorPhone
S01	Arjun	C101	DBMS	Dr. Kumar	9876543210
S01	Arjun	C102	Data Mining	Dr. Mehta	9123456780
S02	Priya	C101	DBMS	Dr. Kumar	9876543210
S03	Kiran	C103	AI	Dr. Rao	9988776655

Looks fine, right? But…

Insertion anomaly: can’t add a new course unless a student enrolls.
Update anomaly: change Dr. Kumar’s number = update multiple rows.
Deletion anomaly: if Priya drops DBMS, we lose all info about the course!

That’s where normalization comes to the rescue.

Step 1: 1NF – First Normal Form

Rule: Eliminate repeating groups, ensure atomic values.

Our table is already atomic, so in SQL we can define it as:

CREATE TABLE StudentCourse1NF (
    StudentID VARCHAR(10),
    StudentName VARCHAR(50),
    CourseID VARCHAR(10),
    CourseName VARCHAR(50),
    Instructor VARCHAR(50),
    InstructorPhone VARCHAR(15)
);

Insert sample data:

INSERT INTO StudentCourse1NF VALUES
('S01', 'Arjun', 'C101', 'DBMS', 'Dr. Kumar', '9876543210'),
('S01', 'Arjun', 'C102', 'Data Mining', 'Dr. Mehta', '9123456780'),
('S02', 'Priya', 'C101', 'DBMS', 'Dr. Kumar', '9876543210'),
('S03', 'Kiran', 'C103', 'AI', 'Dr. Rao', '9988776655');

Data is atomic but anomalies still exist. Let’s move forward.

Step 2: 2NF – Second Normal Form

Rule: Eliminate partial dependency (non-key columns depending only on part of a composite key).

CourseName, Instructor, and InstructorPhone depend only on CourseID.
So let’s split them into separate tables.

CREATE TABLE Student (
    StudentID VARCHAR(10) PRIMARY KEY,
    StudentName VARCHAR(50)
);

CREATE TABLE Course (
    CourseID VARCHAR(10) PRIMARY KEY,
    CourseName VARCHAR(50),
    Instructor VARCHAR(50),
    InstructorPhone VARCHAR(15)
);

CREATE TABLE Enrollment (
    StudentID VARCHAR(10),
    CourseID VARCHAR(10),
    PRIMARY KEY (StudentID, CourseID),
    FOREIGN KEY (StudentID) REFERENCES Student(StudentID),
    FOREIGN KEY (CourseID) REFERENCES Course(CourseID)
);

Now we insert data:

-- Students
INSERT INTO Student VALUES
('S01', 'Arjun'),
('S02', 'Priya'),
('S03', 'Kiran');

-- Courses
INSERT INTO Course VALUES
('C101', 'DBMS', 'Dr. Kumar', '9876543210'),
('C102', 'Data Mining', 'Dr. Mehta', '9123456780'),
('C103', 'AI', 'Dr. Rao', '9988776655');

-- Enrollment (who studies what)
INSERT INTO Enrollment VALUES
('S01', 'C101'),
('S01', 'C102'),
('S02', 'C101'),
('S03', 'C103');

Now we don’t repeat course details for every student.
But there’s still a problem…

Step 3: 3NF – Third Normal Form

Rule: Eliminate transitive dependencies (non-key columns depending on other non-key columns).

Here, InstructorPhone depends on Instructor, not on CourseID.
So let’s give instructors their own table.

CREATE TABLE Instructor (
    InstructorID INT PRIMARY KEY,
    InstructorName VARCHAR(50),
    InstructorPhone VARCHAR(15)
);

CREATE TABLE Course3NF (
    CourseID VARCHAR(10) PRIMARY KEY,
    CourseName VARCHAR(50),
    InstructorID INT,
    FOREIGN KEY (InstructorID) REFERENCES Instructor(InstructorID)
);

Insert values:

-- Instructors
INSERT INTO Instructor VALUES
(1, 'Dr. Kumar', '9876543210'),
(2, 'Dr. Mehta', '9123456780'),
(3, 'Dr. Rao', '9988776655');

-- Courses
INSERT INTO Course3NF VALUES
('C101', 'DBMS', 1),
('C102', 'Data Mining', 2),
('C103', 'AI', 3);

Query Time!

Let’s pull out all students with their courses and instructors:

SELECT s.StudentName, c.CourseName, i.InstructorName, i.InstructorPhone
FROM Enrollment e
JOIN Student s ON e.StudentID = s.StudentID
JOIN Course3NF c ON e.CourseID = c.CourseID
JOIN Instructor i ON c.InstructorID = i.InstructorID;

Output :

StudentName	CourseName	InstructorName	InstructorPhone
Arjun	DBMS	Dr. Kumar	9876543210
Arjun	Data Mining	Dr. Mehta	9123456780
Priya	DBMS	Dr. Kumar	9876543210
Kiran	AI	Dr. Rao	9988776655

Key Takeaways

1NF: Atomic values, no repeating groups.
2NF: No partial dependency.
3NF: No transitive dependency.

In real projects, normalized tables reduce redundancy, anomalies, and maintenance pain.

That’s it! You’ve just walked from messy unnormalized data → fully normalized schema with SQL.
Try this in DB Fiddle or SQLite Online and see it in action.

CRUD OPERATIONS

Santhosh_M — Mon, 29 Sep 2025 12:59:48 +0000

Mastering MongoDB CRUD with a Simple College Student Schema 🎓

Databases are the backbone of modern applications — and MongoDB, with its flexible NoSQL design, has become a developer favorite.

In this blog, I’ll walk you through CRUD (Create, Read, Update, Delete) operations in MongoDB Atlas, using a simple yet relatable example: managing college student records.

📌 Schema: students Collection

{
"student_id": "S001",
"name": "Santhosh",
"age": 20,
"department": "CSBS",
"year": 2,
"cgpa": 9
}

Create (Insert)

Insert 5 student records:

db.students.insertMany([
{ "student_id": "S001", "name": "Santhosh", "age": 20, "department": "CSBS", "year": 2, "cgpa": 9 },
{ "student_id": "S002", "name": "Priya", "age": 21, "department": "CSE", "year": 3, "cgpa": 8.7 },
{ "student_id": "S003", "name": "Arjun", "age": 19, "department": "ECE", "year": 1, "cgpa": 7.2 },
{ "student_id": "S004", "name": "Meena", "age": 22, "department": "CSE", "year": 3, "cgpa": 9.1 },
{ "student_id": "S005", "name": "Vikram", "age": 20, "department": "IT", "year": 2, "cgpa": 8.0 }
])

✔ Inserts multiple documents at once.

Read (Query)

👉 Display all records

db.students.find().pretty()

👉 Find students with CGPA > 8

db.students.find({ cgpa: { $gt: 8 } })

👉 Find students in Computer Science (CSE)

db.students.find({ department: "CSE" })

Update

👉 Update CGPA of a specific student

db.students.updateOne(
{ student_id: "S002" },
{ $set: { cgpa: 9.0 } }
)

👉 Increase year for all 3rd-year students

db.students.updateMany(
{ year: 3 },
{ $inc: { year: 1 } }
)

Delete

👉 Delete one student by student_id

db.students.deleteOne({ student_id: "S003" })

👉 Delete all students with CGPA < 7.5

db.students.deleteMany({ cgpa: { $lt: 7.5 } })

Deliverables

✅ MongoDB CRUD queries (insert, find, update, delete)

✅ Export of final collection (JSON/CSV)

Key Takeaways

CRUD in MongoDB is schema-flexible and beginner-friendly.

Using a real-world example (students) makes learning easier.

These basics set the stage for aggregations, indexing, and scaling.

Tried MongoDB CRUD with your own dataset? Share in the comments!
If you found this useful, drop a and connect with me on LinkedIn.

College Management Course

Santhosh_M — Thu, 21 Aug 2025 17:17:40 +0000

🎓 College Database using Oracle LiveSQL

This project shows how to design and query a simple College Management System using Oracle LiveSQL. We’ll create tables, insert data, and run queries with joins, aggregates, views, and procedures.

🏗 Schema Design

CREATE TABLE Faculty (
  FacultyID NUMBER PRIMARY KEY,
  FacultyName VARCHAR2(50) NOT NULL,
  Dept VARCHAR2(30),
  Email VARCHAR2(50) UNIQUE
);

CREATE TABLE Students (
  StudentID NUMBER PRIMARY KEY,
  Name VARCHAR2(50) NOT NULL,
  Dept VARCHAR2(30),
  DOB DATE,
  Email VARCHAR2(50) UNIQUE,
  PhoneNo NUMBER(10)
);

CREATE TABLE Courses (
  CourseID NUMBER PRIMARY KEY,
  CourseName VARCHAR2(50) NOT NULL,
  Credits NUMBER(2) CHECK (Credits BETWEEN 1 AND 5)
);

CREATE TABLE Enrollments (
  EnrollID NUMBER PRIMARY KEY,
  StudentID NUMBER REFERENCES Students(StudentID),
  CourseID NUMBER REFERENCES Courses(CourseID),
  Grade CHAR(2)
);

👉 Used PRIMARY KEY, UNIQUE, and CHECK to maintain integrity.

📥 Insert Data

-- Students
INSERT INTO Students VALUES (1, 'Arjun', 'CSE', DATE '2004-05-15', 'arjun@college.com', 9876543210);
INSERT INTO Students VALUES (2, 'Meera', 'ECE', DATE '2003-11-20', 'meera@college.com', 9876543211);

-- Courses
INSERT INTO Courses VALUES (101, 'Database Systems', 4);
INSERT INTO Courses VALUES (102, 'Operating Systems', 3);

-- Enrollments
INSERT INTO Enrollments VALUES (1, 1, 101, 'A');
INSERT INTO Enrollments VALUES (2, 2, 102, 'B');

👉 Added students, courses, and their enrollments.

🔍 Queries

1. String Functions & Aggregates

SELECT UPPER(Name) AS StudentNameUpper, LENGTH(Email) AS EmailLength
FROM Students;

✔ Converts names to uppercase & shows email length.

SELECT AVG(Credits) AS AvgCredits, COUNT(*) AS TotalCourses
FROM Courses;

✔ Finds average credits & total courses.

2. Joins

SELECT s.Name, c.CourseName, e.Grade
FROM Students s
JOIN Enrollments e ON s.StudentID = e.StudentID
JOIN Courses c ON e.CourseID = c.CourseID;

✔ Shows each student’s course and grade.

3. Group By + Having

SELECT Dept, COUNT(*) AS StudentCount
FROM Students
GROUP BY Dept
HAVING COUNT(*) > 0;

✔ Counts students per department.

👁 Views

CREATE OR REPLACE VIEW StudentCoursesView AS
SELECT s.Name, c.CourseName, e.Grade
FROM Students s
JOIN Enrollments e ON s.StudentID = e.StudentID
JOIN Courses c ON e.CourseID = c.CourseID;

✔ Reusable view for student-course-grade mapping.

⚙ Stored Procedure

CREATE OR REPLACE PROCEDURE UpdateGrade(
    p_StudentID IN NUMBER,
    p_CourseID IN NUMBER,
    p_NewGrade IN CHAR
) AS
BEGIN
    UPDATE Enrollments
    SET Grade = p_NewGrade
    WHERE StudentID = p_StudentID AND CourseID = p_CourseID;
    COMMIT;
END;

✔ Easy way to update grades with parameters.

✅ Conclusion

This mini project demonstrates:

Table creation with constraints
Inserting sample data
Running string, aggregate, and join queries
Using GROUP BY and HAVING
Creating Views
Writing a Stored Procedure

A neat College Database built entirely on **Oracle

gangeswara

Santhosh_M — Thu, 21 Aug 2025 13:37:02 +0000

gangesware

Santhosh_M — Thu, 21 Aug 2025 13:36:29 +0000