ORM আর migration — সুবিধা আর ফাঁদ

১ · দুই জগতের অমিল — object আর টেবিল

পর্ব ৪-এ দেখেছেন, প্রোগ্রামের ভাষা আর relational ডেটাবেস দুনিয়াকে দুইভাবে দেখে। Python, Java বা JavaScript-এ একজন গ্রাহক একটি object: তার ভেতরে নাম, শহর, আর তার অর্ডারগুলোর একটি তালিকা। ডেটাবেসে একই গ্রাহক customers টেবিলের একটি সারি, আর তার অর্ডারগুলো আলাদা orders টেবিলে, foreign key দিয়ে জোড়া। এই অমিলের নাম impedance mismatch.

পর্ব ৪৯-এ দেখেছেন driver দিয়ে সরাসরি SQL পাঠানো, parameterized query আর connection pool. সেখানে অনুবাদের সব কাজ আপনার: SELECT-এর সারি থেকে object বানানো, object বদলালে UPDATE লেখা। ORM (Object-Relational Mapping) এই কাজটি একটি library-তে তুলে দেয়।

২ · ORM ভেতরে কী করে — session, identity map আর unit of work

ORM-এর কাজ চার ভাগে। এর বেশিরভাগ নকশার নাম এসেছে Martin Fowler-এর ২০০২ সালের বই Patterns of Enterprise Application Architecture থেকে।

নিচের stepper-এ SQLAlchemy 2.0-এর একটি session-এর পুরো জীবন দেখুন। ডান পাশের টেবিলে খেয়াল করুন, কোন লাইনে আসলে SQL যায় আর কোনটিতে যায় না:

দুই ধরনের ORM নকশা চিনে রাখুন। Active Record-এ object নিজেই নিজেকে সেভ করে (customer.save()) — Rails, Laravel-এর Eloquent, Django-ও অনেকটা এই ধাঁচে। Data Mapper-এ object সাধারণ class, আলাদা একটি স্তর (session বা EntityManager) তাকে ডেটাবেসে নেয় — SQLAlchemy, Hibernate/JPA. প্রথমটি শুরুতে সহজ, দ্বিতীয়টি বড় ডোমেইনে নমনীয়।

৩ · একই মডেল চার ORM-এ, আর ORM বনাম query builder বনাম raw SQL

এবার দোকানের নমুনা ডেটাবেসের দুটি টেবিল মডেল করি: customers (customer_id, name, city, phone, joined_on) আর orders (order_id, customer_id, order_date, status). একজন গ্রাহকের অনেক অর্ডার — ১:N সম্পর্ক। প্রতিটি ট্যাবে প্রথমে মডেল, তারপর একই query: “ঢাকার গ্রাহক, তাদের অর্ডারসহ”।

from sqlalchemy import ForeignKey, String, select
from sqlalchemy.orm import (DeclarativeBase, Mapped, Session,
                            mapped_column, relationship, selectinload)

class Base(DeclarativeBase):
    pass

class Customer(Base):
    __tablename__ = "customers"
    customer_id: Mapped[int] = mapped_column(primary_key=True)
    name: Mapped[str] = mapped_column(String(100))
    city: Mapped[str | None]
    orders: Mapped[list["Order"]] = relationship(back_populates="customer")

class Order(Base):
    __tablename__ = "orders"
    order_id: Mapped[int] = mapped_column(primary_key=True)
    customer_id: Mapped[int] = mapped_column(ForeignKey("customers.customer_id"))
    order_date: Mapped[str]
    status: Mapped[str] = mapped_column(String(20))
    customer: Mapped["Customer"] = relationship(back_populates="orders")

with Session(engine) as session:
    stmt = (select(Customer).where(Customer.city == "Dhaka")
            .options(selectinload(Customer.orders)))
    for c in session.scalars(stmt):
        print(c.name, len(c.orders))

from django.db import models

class Customer(models.Model):
    customer_id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=100)
    city = models.CharField(max_length=50, null=True)

    class Meta:
        db_table = "customers"

class Order(models.Model):
    order_id = models.AutoField(primary_key=True)
    customer = models.ForeignKey(Customer, on_delete=models.PROTECT,
                                 related_name="orders",
                                 db_column="customer_id")
    order_date = models.DateField()
    status = models.CharField(max_length=20)

    class Meta:
        db_table = "orders"

qs = Customer.objects.filter(city="Dhaka").prefetch_related("orders")
for c in qs:
    print(c.name, len(c.orders.all()))

@Entity
@Table(name = "customers")
public class Customer {
    @Id
    @Column(name = "customer_id")
    private Long id;
    private String name;
    private String city;
    @OneToMany(mappedBy = "customer")          // default: LAZY
    private List<Order> orders = new ArrayList<>();
}

@Entity
@Table(name = "orders")
public class Order {
    @Id
    @Column(name = "order_id")
    private Long id;
    @ManyToOne(fetch = FetchType.LAZY)         // default would be EAGER
    @JoinColumn(name = "customer_id")
    private Customer customer;
    private String status;
}

List<Customer> list = em.createQuery(
        "select c from Customer c left join fetch c.orders where c.city = :city",
        Customer.class)
    .setParameter("city", "Dhaka")
    .getResultList();

model Customer {
  id     Int     @id @map("customer_id")
  name   String
  city   String?
  orders Order[]
  @@map("customers")
}

model Order {
  id         Int      @id @map("order_id")
  customerId Int      @map("customer_id")
  status     String
  customer   Customer @relation(fields: [customerId], references: [id])
  @@map("orders")
}

// query.ts
const customers = await prisma.customer.findMany({
  where: { city: "Dhaka" },
  include: { orders: true },
});
for (const c of customers) console.log(c.name, c.orders.length);

কোন ভাষায় কোন ORM

তিনটি পথ — ORM, query builder, raw SQL

বাস্তবে বেশিরভাগ দল তিনটিই মেশায়: সাধারণ CRUD ORM-এ, রিপোর্ট বা গরম পথে (hot path) raw SQL. প্রায় সব ORM-এ raw SQL চালানোর পথ আছে (session.execute(text(...)), Model.objects.raw(), createNativeQuery, $queryRaw). সেখানেও মান বসান parameter দিয়ে, string জুড়ে নয় — নইলে ORM-এর দেওয়া SQL injection সুরক্ষা হারাবেন (পর্ব ৫১)।

সুবিধাগুলো আসল: কম কোডে বেশি কাজ; সব query-তে parameter স্বয়ংক্রিয়ভাবে, তাই injection-এর ঝুঁকি কম; একই মডেল SQLite-এ পরীক্ষা আর PostgreSQL-এ production — কিছুটা portability; আর schema-র একটি জায়গায় বর্ণনা, যা থেকে migration-ও বানানো যায়। portability অবশ্য সীমিত: dialect-এর পার্থক্য (পর্ব ৩১) — যেমন তারিখ বা case-sensitivity — ORM পুরো ঢাকতে পারে না।

৪ · Lazy, eager আর N+1 — সবচেয়ে পরিচিত ফাঁদ

Lazy loading মানে সম্পর্কিত ডেটা আনা হয় প্রথম ছোঁয়ার মুহূর্তে। Eager loading মানে মূল query-র সাথেই আগাম আনা। lazy শুনতে সাশ্রয়ী — যা লাগবে না, তা আনব কেন? কিন্তু লুপের ভেতরে পড়লেই বিপদ: N+1 সমস্যা.

এবার ORM ঠিক যে SQL পাঠায়, সেটিই চালান। নিচের এডিটর দোকানের নমুনা ডেটাবেসে (db-shop) চলে: customers-এ ৮ জন গ্রাহক, orders-এ ১০টি অর্ডার (order_id, customer_id, order_date, status), সাথে products, categories আর order_items. প্রথমে lazy loading-এর চারটি query:

-- lazy loading: ১টি query, তারপর প্রতি গ্রাহকে ১টি
SELECT customer_id, name FROM customers WHERE city = 'Dhaka';
SELECT order_id, status FROM orders WHERE customer_id = 1;
SELECT order_id, status FROM orders WHERE customer_id = 3;
SELECT order_id, status FROM orders WHERE customer_id = 8;

এবার joinedload বা join fetch যে SQL পাঠায়:

SELECT c.customer_id, c.name, o.order_id, o.status
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
WHERE c.city = 'Dhaka'
ORDER BY c.customer_id, o.order_id;

এজন্যই “অনেক” দিকের তালিকায় দ্বিতীয় কৌশলটি প্রায়ই ভালো — selectinload, prefetch_related বা Prisma-র include যেমন করে:

SELECT customer_id, name FROM customers WHERE city = 'Dhaka';
-- প্রথম query-র id-গুলো দিয়ে দ্বিতীয় query
SELECT customer_id, order_id, status FROM orders
WHERE customer_id IN (1, 3, 8)
ORDER BY customer_id, order_id;

ORM-এর ভেতরের যন্ত্রটি আসলে কত ছোট, নিজে বানিয়ে দেখুন। নিচের Python প্রোগ্রাম শুধু standard library-র sqlite3 দিয়ে একটি খুদে ORM: lazy loading-ওয়ালা orders, identity map, আর snapshot মিলিয়ে change tracking. set_trace_callback প্রতিটি পাঠানো SQL গুনে রাখে:

import sqlite3
con = sqlite3.connect(":memory:", isolation_level=None)
con.executescript("""CREATE TABLE customers (customer_id INTEGER PRIMARY KEY, name TEXT, city TEXT);
CREATE TABLE orders (order_id INTEGER PRIMARY KEY, customer_id INTEGER, status TEXT);
INSERT INTO customers VALUES (1,'Rahim','Dhaka'), (3,'Sabbir','Dhaka'), (8,'Mitu','Dhaka');
INSERT INTO orders VALUES (1001,1,'delivered'), (1003,1,'shipped'), (1009,1,'pending'), (1004,3,'cancelled'), (1008,8,'shipped');""")
log = []; con.set_trace_callback(log.append)     # every SQL statement we send
class Customer:
    def __init__(self, cid, name):
        self.id, self.name, self._orders = cid, name, None
    @property
    def orders(self):                             # lazy loading
        if self._orders is None:
            self._orders = [r[0] for r in con.execute("SELECT order_id FROM orders WHERE customer_id = ?", (self.id,))]
        return self._orders
class Session:
    def __init__(self):
        self.identity, self.snapshot = {}, {}
    def get(self, cid, name=None):                # identity map
        if cid not in self.identity:
            if name is None: name = con.execute("SELECT name FROM customers WHERE customer_id = ?", (cid,)).fetchone()[0]
            self.identity[cid], self.snapshot[cid] = Customer(cid, name), name
        return self.identity[cid]
    def flush(self):                              # change tracking (dirty check)
        for cid, c in self.identity.items():
            if c.name != self.snapshot[cid]:
                con.execute("UPDATE customers SET name = ? WHERE customer_id = ?", (c.name, cid))
                self.snapshot[cid] = c.name
s = Session()                                    # 1) lazy loading -> N+1
for cid, name in con.execute("SELECT customer_id, name FROM customers WHERE city = 'Dhaka'").fetchall():
    print(s.get(cid, name).name, len(s.get(cid).orders))
print("lazy:", len(log), "queries"); log.clear()

s = Session()                                     # 2) eager loading: one JOIN
for cid, name, oid in con.execute("""SELECT c.customer_id, c.name, o.order_id FROM customers c
        LEFT JOIN orders o ON o.customer_id = c.customer_id WHERE c.city = 'Dhaka'""").fetchall():
    c = s.get(cid, name)
    c._orders = (c._orders or []) + ([oid] if oid else [])
print({c.name: len(c.orders) for c in s.identity.values()}, "eager:", len(log), "query"); log.clear()

a, b = s.get(1), s.get(1)                         # 3) same row -> same object, no new query
print("a is b:", a is b, "| queries:", len(log))
a.name = "Rahim Uddin"; s.flush(); s.flush()      # 4) unit of work: only changed rows, once
print([q for q in log if q.startswith("UPDATE")])

Rahim 3
Sabbir 1
Mitu 1
lazy: 4 queries
{'Rahim': 3, 'Sabbir': 1, 'Mitu': 1} eager: 1 query
a is b: True | queries: 0
["UPDATE customers SET name = 'Rahim Uddin' WHERE customer_id = 1"]

৫ · আরও ফাঁদ — over-fetching, লুকানো query, bulk কাজ আর session-এর সীমা

Over-fetching আর Python-এ হিসাব

ORM সাধারণত পুরো object আনে — মানে সব কলাম, অনেকটা SELECT *-এর মতো। একটি বড় JSON বা লেখার কলাম থাকলে তালিকার পাতাতেও সেটি নেটওয়ার্কে আসে: over-fetching. আরও খারাপ: শুধু গুনতে চেয়ে পুরো তালিকা আনা — len(c.orders). হিসাবটি ডেটাবেসেই করুন:

-- len(c.orders) প্রত্যেকের জন্য = সব অর্ডার টেনে আনা
-- তার বদলে: একটি query, শুধু সংখ্যা
SELECT c.name, COUNT(o.order_id) AS n_orders
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id
ORDER BY n_orders DESC, c.name;

লুকানো query আর leaky abstraction — ORM-এর SQL দেখুন

Joel Spolsky-র ২০০২ সালের “Law of Leaky Abstractions” বলে: প্রতিটি অ-তুচ্ছ abstraction কোথাও না কোথাও ফুটো — নিচের জটিলতা বেরিয়ে আসে। ORM-এর ফুটো হলো গতি: কোড দেখে বোঝা যায় না কয়টি আর কেমন SQL যাবে। তাই প্রথম অভ্যাস — ORM-এর তৈরি SQL লগে দেখা:

# SQLAlchemy
engine = create_engine(url, echo=True)          # প্রতিটি SQL আর parameter লগে
print(stmt)                                      # একটি statement-এর SQL দেখা

# Django (settings.py, শুধু DEBUG=True হলে)
LOGGING = {"version": 1,
           "handlers": {"console": {"class": "logging.StreamHandler"}},
           "loggers": {"django.db.backends": {"handlers": ["console"],
                                              "level": "DEBUG"}}}
print(Customer.objects.filter(city="Dhaka").query)

# Hibernate / Spring Boot (application.properties)
#   logging.level.org.hibernate.SQL=DEBUG
#   logging.level.org.hibernate.orm.jdbc.bind=TRACE   (Hibernate 6: parameter)
# Prisma
#   const prisma = new PrismaClient({ log: ["query"] });

লগ থেকে SQL পেলে তার plan দেখুন — পর্ব ৪১-এর মতো। ORM foreign key-র কলামে নিজে থেকে index বানাবে, এমন ভরসা করবেন না: Django বানায়, কিন্তু SQLAlchemy বা অনেক ORM বানায় না, আর PostgreSQL-ও foreign key-তে নিজে index দেয় না। selectinload-এর পাঠানো IN query-টি নিয়ে দেখি:

EXPLAIN QUERY PLAN
SELECT order_id, status FROM orders WHERE customer_id IN (1, 3, 8);
CREATE INDEX idx_orders_customer ON orders(customer_id);
EXPLAIN QUERY PLAN
SELECT order_id, status FROM orders WHERE customer_id IN (1, 3, 8);

Bulk কাজ — লুপে নয়, একটি statement-এ

“সব Electronics পণ্যের দাম ১০% কমাও” ORM-এর সহজ পথে: সব object আনা, লুপে দাম বদলানো, commit — মানে N সারি পড়া আর N টি UPDATE. সেট-ভিত্তিক একটি UPDATE ... WHERE (পর্ব ১৪) একই কাজ এক statement-এ করে। প্রতিটি ORM-এ এর পথ আছে: SQLAlchemy-তে session.execute(update(Product).where(...).values(price=Product.price * 0.9)), Django-তে filter(...).update(price=F("price") * 0.9), JPA-তে JPQL update; বহু সারি ঢোকাতে bulk_create, insert()-এ তালিকা, বা Hibernate-এর JDBC batching. সতর্কতা: এই পথে ORM-এর object-স্তরের যন্ত্র (signal, callback, session-এর object) বাদ পড়ে — যেমন Django-র update() মডেলের save() বা signal চালায় না।

আরেকটি লুকানো বিপদ পর্ব ৪৬-এর lost update: p.stock = p.stock - 1 মানে আগে পড়া, পাইথনে বিয়োগ, পরে লেখা। দুজন একসাথে করলে একটি বিয়োগ হারায়। সমাধান — ডেটাবেসে হিসাব (F("stock") - 1, Product.stock - 1), অথবা optimistic locking: SQLAlchemy-র version_id_col, JPA-র @Version.

Session আর transaction-এর সীমা ভুল করা

• Session বন্ধের পর lazy load: object session-এর বাইরে চলে গেলে (detached) সম্পর্ক ছুঁলে ত্রুটি — SQLAlchemy-তে DetachedInstanceError, Hibernate-এ LazyInitializationException. সমাধান: যা লাগবে session থাকতেই eager-এ আনুন।
• অনন্তকাল খোলা session: পুরো অ্যাপে একটি global session মানে identity map ফুলতে থাকে, পুরোনো ডেটা দেখায়, আর দীর্ঘ transaction lock ধরে রাখে (পর্ব ৪৭)। নিয়ম: একটি web request = একটি session = সাধারণত একটি transaction.
• লুপের ভেতর commit: প্রতিটি সারিতে commit মানে প্রতিটিতে fsync (পর্ব ৪৮), আর মাঝপথে ব্যর্থ হলে অর্ধেক কাজ থেকে যায়। একসাথে যা হওয়া উচিত, তা একটি transaction-এ রাখুন।
• transaction-এর ভেতরে ধীর বাইরের কাজ: commit-এর আগে ইমেইল পাঠানো বা পেমেন্ট গেটওয়ে ডাকা মানে lock ধরে অপেক্ষা; আর rollback হলে ইমেইল তো ফেরানো যায় না।

৬ · Schema migration — schema-র সংস্করণ নিয়ন্ত্রণ

কোড git-এ থাকে, প্রতিটি বদল review হয়। কিন্তু ডেটাবেসের schema? কেউ production-এ হাতে ALTER TABLE চালালে staging আর developer-এর ল্যাপটপের সাথে মিল থাকে না — schema drift. Migration এর উত্তর: প্রতিটি schema বদল একটি ক্রমিক ফাইল, কোডের সাথে git-এ, review হয়ে, প্রতিটি পরিবেশে একই ক্রমে চলে।

প্রায় সব tool-এর মূল একই: প্রতিটি migration-এর একটি up (এগোনো) আর ঐচ্ছিক down (ফেরানো) অংশ। একটি Alembic migration দেখতে এমন:

"""add customer email"""
from alembic import op
import sqlalchemy as sa

revision = "0005"
down_revision = "0004"          # আগের migration — এভাবেই শিকল তৈরি হয়

def upgrade() -> None:
    op.add_column("customers", sa.Column("email", sa.String(200), nullable=True))
    op.create_index("ix_customers_email", "customers", ["email"], unique=True)

def downgrade() -> None:
    op.drop_index("ix_customers_email", table_name="customers")
    op.drop_column("customers", "email")

tool ডেটাবেসের ভেতরের একটি টেবিলে লিখে রাখে কোন migration চলেছে। Rails-এ এর নাম schema_migrations, এই পর্বেও আমরা সেই নামই নেব। চালানোর সময় tool ফাইলের তালিকা আর টেবিলের তালিকা মেলায়: যা টেবিলে নেই, তা চালায়, ক্রমে। নিচের এডিটরে এমন একটি টেবিল (version, name, applied_at, checksum) আছে; সাথে একটি অস্থায়ী files টেবিলে রিপোজিটরির migration ফাইলের তালিকা:

SELECT version, name, applied_at FROM schema_migrations ORDER BY version;
CREATE TEMP TABLE files (version TEXT);
INSERT INTO files VALUES ('0001'), ('0002'), ('0003'), ('0004'), ('0005'), ('0006');
-- কোডে আছে, ডেটাবেসে চলেনি: এগুলো এখন চলবে
SELECT version AS pending FROM files
EXCEPT SELECT version FROM schema_migrations ORDER BY 1;
-- ডেটাবেসে চলেছে, কোডে নেই: সতর্কসংকেত
SELECT version AS unknown_to_code FROM schema_migrations
EXCEPT SELECT version FROM files;

এবার পুরো যন্ত্রটি নিজে বানান। নিচের runner তিনটি সংস্করণযুক্ত migration চালায়, প্রতিটি নিজের transaction-এ, আর হিসাব রাখে schema_migrations-এ — সাথে একটি checksum, যাতে চলে যাওয়া migration পরে কেউ বদলালে ধরা পড়ে (Flyway ঠিক এটি করে):

import sqlite3, hashlib
MIGRATIONS = [   # (version, name, up SQL) -- in a real project: one file per migration
    ("001", "create_customers", "CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT NOT NULL)"),
    ("002", "create_orders", "CREATE TABLE orders (id INTEGER PRIMARY KEY, "
            "customer_id INTEGER NOT NULL REFERENCES customers(id), status TEXT NOT NULL)"),
    ("003", "add_customer_city", "ALTER TABLE customers ADD COLUMN city TEXT"),
]
checksum = lambda sql: hashlib.sha256(sql.encode()).hexdigest()[:10]
def migrate(con, migrations):
    con.execute("CREATE TABLE IF NOT EXISTS schema_migrations "
                "(version TEXT PRIMARY KEY, name TEXT NOT NULL, checksum TEXT NOT NULL)")
    done = dict(con.execute("SELECT version, checksum FROM schema_migrations"))
    applied = 0
    for version, name, sql in migrations:
        if version in done:
            if done[version] != checksum(sql):
                raise RuntimeError(f"{version} was edited after it was applied")
            continue
        con.execute("BEGIN")                      # one transaction per migration
        try:
            con.execute(sql)
            con.execute("INSERT INTO schema_migrations VALUES (?, ?, ?)", (version, name, checksum(sql)))
            con.execute("COMMIT")
            print("  applied", version, name); applied += 1
        except sqlite3.Error as e:
            con.execute("ROLLBACK")
            print("  FAILED", version, "->", e)
            return
    if not applied: print("  nothing to do")
con = sqlite3.connect(":memory:", isolation_level=None)   # we control BEGIN/COMMIT
print("day 1:"); migrate(con, MIGRATIONS[:2])
print("day 2:"); migrate(con, MIGRATIONS)
print("again:"); migrate(con, MIGRATIONS)                 # nothing to do
con.execute("INSERT INTO customers (name, city) VALUES ('Rahim', 'Dhaka')")
con.execute("INSERT INTO orders (customer_id, status) VALUES (1, 'pending')")
bad = ("004", "add_total", "ALTER TABLE orders ADD COLUMN total INTEGER NOT NULL")
print("day 3:"); migrate(con, MIGRATIONS + [bad])
print(con.execute("SELECT version, name, checksum FROM schema_migrations").fetchall())
print("orders columns:", [r[1] for r in con.execute("PRAGMA table_info(orders)")])
edited = MIGRATIONS[:2] + [("003", "add_customer_city", "ALTER TABLE customers ADD COLUMN town TEXT")]
try:
    migrate(con, edited)
except RuntimeError as e:
    print("error:", e)

day 1:
  applied 001 create_customers
  applied 002 create_orders
day 2:
  applied 003 add_customer_city
again:
  nothing to do
day 3:
  FAILED 004 -> Cannot add a NOT NULL column with default value NULL
[('001', 'create_customers', '478f22b99a'), ('002', 'create_orders', 'c8dcee34c5'), ('003', 'add_customer_city', '19883fe4dd')]
orders columns: ['id', 'customer_id', 'status']
error: 003 was edited after it was applied

migration-কে transaction-এ মোড়ানো তখনই কাজ করে, যখন ডেটাবেস DDL-কেও transaction-এ রাখতে পারে (transactional DDL, পর্ব ৩১)। PostgreSQL আর SQLite পারে; MySQL-এ প্রায় প্রতিটি DDL নিজে থেকে commit করে (implicit commit). ফলে MySQL-এ দুই ধাপের migration-এর দ্বিতীয় ধাপ ব্যর্থ হলে প্রথমটি থেকে যায় — অর্ধেক migration. নিচে একই অবস্থা দেখুন; এডিটর প্রথম ত্রুটিতে থামে:

BEGIN;
ALTER TABLE orders ADD COLUMN total REAL;
ALTER TABLE customers ADD COLUMN email TEXT NOT NULL;
COMMIT;

৭ · Downtime ছাড়া schema বদল — expand–contract

বড় অ্যাপে deploy মানে একসাথে সব সার্ভার বদলানো নয়: কয়েক মিনিট ধরে কিছু সার্ভারে পুরোনো কোড, কিছুতে নতুন। আর migration চলে deploy-এর আগে বা মাঝে। তাই প্রতিটি schema বদলকে পুরোনো আর নতুন দুই কোডের সাথেই চলতে হবে। কলামের নাম বদলানো বা NOT NULL কলাম যোগ করা এক ধাপে করলে পুরোনো কোড ভাঙে। পর্ব ২৩-এ দেখা expand–contract (parallel change নামেও পরিচিত) কাজটিকে ভাঙে নিরাপদ ছোট ধাপে।

উদাহরণ: products.price REAL (টাকা, দশমিক) — floating point-এ পয়সার হিসাব ভুল হতে পারে (পর্ব ১৩)। লক্ষ্য: পূর্ণসংখ্যায় পয়সা, price_paisa INTEGER NOT NULL, আর শেষে price বাদ।

expand আর backfill লাইভ দেখুন। backfill-এ দুটি ব্যাচ, তারপর contract-এর আগের যাচাই:

-- M1 expand
ALTER TABLE products ADD COLUMN price_paisa INTEGER;
-- M2 backfill, ব্যাচে (বাস্তবে হাজার সারি করে)
UPDATE products SET price_paisa = CAST(ROUND(price * 100) AS INTEGER)
WHERE price_paisa IS NULL AND product_id BETWEEN 101 AND 105;
UPDATE products SET price_paisa = CAST(ROUND(price * 100) AS INTEGER)
WHERE price_paisa IS NULL AND product_id BETWEEN 106 AND 110;
-- contract-এর আগে যাচাই
SELECT COUNT(*) AS still_null FROM products WHERE price_paisa IS NULL;
SELECT product_id, price, price_paisa FROM products WHERE product_id IN (101, 109);

backfill চলার সময়েও পুরোনো কোড শুধু price লিখতে পারে। দুই কলাম মেলানোর একটি পথ — ক্ষণস্থায়ী sync trigger:

ALTER TABLE products ADD COLUMN price_paisa INTEGER;
CREATE TRIGGER products_sync_paisa AFTER UPDATE OF price ON products
BEGIN
  UPDATE products SET price_paisa = CAST(ROUND(NEW.price * 100) AS INTEGER)
  WHERE product_id = NEW.product_id;
END;
-- পুরোনো অ্যাপ শুধু price বদলায়
UPDATE products SET price = 1150 WHERE product_id = 102;
SELECT product_id, price, price_paisa FROM products WHERE product_id IN (102, 103);

SET lock_timeout = '3s';     -- lock না পেলে অপেক্ষা না করে ব্যর্থ হও
ALTER TABLE products
  ADD CONSTRAINT price_paisa_not_null CHECK (price_paisa IS NOT NULL) NOT VALID;
ALTER TABLE products VALIDATE CONSTRAINT price_paisa_not_null;
ALTER TABLE products ALTER COLUMN price_paisa SET NOT NULL;   -- PG 12+: scan নেই
ALTER TABLE products DROP CONSTRAINT price_paisa_not_null;

-- transaction-এর বাইরে চালাতে হয় (Alembic: autocommit_block, Django: atomic = False)
CREATE INDEX CONCURRENTLY idx_orders_customer ON orders (customer_id);

lock_timeout কেন? ALTER-এর lock পেতে সেটি চলমান দীর্ঘ query-র পেছনে লাইনে দাঁড়ায়, আর তার পেছনে বাকি সব query আটকে যায় — এক মুহূর্তের ALTER-ও পুরো সাইট থামিয়ে দিতে পারে। ব্যর্থ হয়ে পরে আবার চেষ্টা করা ভালো। MySQL-এ নতুন সংস্করণগুলোতে অনেক ALTER ALGORITHM=INSTANT বা online DDL-এ চলে; বড় টেবিলে GitHub-এর gh-ost বা Percona-র pt-online-schema-change-এর মতো online schema change tool ব্যবহার হয়।

Schema migration বনাম data migration

Data migration ডেটার রূপ বদলায় — backfill, একটি কলাম দুই ভাগ করা, পুরোনো status কোড নতুন নামে আনা। দুটি আলাদা রাখুন: schema migration ছোট আর দ্রুত, data migration দীর্ঘ আর ব্যাচে, প্রায়ই আলাদা job হিসেবে। data migration-এ ORM-এর বর্তমান মডেল import করবেন না — এক বছর পরে মডেল বদলে গেলে পুরোনো migration ভেঙে যাবে। Django তাই data migration-এ apps.get_model() দিয়ে সেই সময়ের “ঐতিহাসিক” মডেল দেয়; Alembic-এ সাধারণ পরামর্শ সরাসরি SQL বা Core ব্যবহার করা।

৮ · দলে migration — conflict, rollback, seeding আর পরিবেশ

Rollback — “down” কেন প্রায়ই কাগুজে

কাগজে প্রতিটি up-এর একটি down আছে। বাস্তবে: DROP COLUMN-এর down কলাম ফিরিয়ে আনে, কিন্তু ডেটা নয়। নতুন কলামে ঘণ্টাখানেক ধরে যে ডেটা লেখা হয়েছে, down চালালে তা হারায়। data migration (দুটি কলাম জোড়া, মান রূপান্তর) প্রায়ই উল্টানো অসম্ভব। আর down migration কেউ নিয়মিত চালায় না, তাই সেগুলো প্রায়ই পরীক্ষাহীন — বিপদের দিনে নিজেই ভাঙে। Prisma Migrate তাই নিজে থেকে down migration বানায় না, আর Flyway-এর undo শুধু পেইড সংস্করণে।

বাস্তবের নীতি roll forward: ভুল হলে আরেকটি নতুন migration দিয়ে সামনে এগিয়ে ঠিক করা। expand–contract এটি সহজ করে, কারণ শেষ ধাপের আগে প্রতিটি ধাপে পুরোনো কোড চলে — কোড ফেরানো যায়, schema ফেরাতে হয় না। আর বড় migration-এর আগে backup, যা থেকে restore পরীক্ষা করা (পর্ব ৫২)।

Seeding আর তিন পরিবেশ

Seeding মানে ডেটাবেসে শুরুর ডেটা বসানো। দুই রকম: reference data (বিভাগের তালিকা, ভূমিকা, দেশের কোড), যা সব পরিবেশে লাগে — এটি migration-এ রাখা যায়; আর নমুনা বা পরীক্ষার ডেটা (বানানো গ্রাহক, অর্ডার), শুধু dev আর test-এ — Django fixture, Rails db/seeds.rb, Laravel seeder, prisma db seed, আর factory_boy বা Faker-এর মতো library দিয়ে। production-এ বানানো ডেটা কখনো নয়।

৯ · AI-এর যুগে ORM আর migration

AI ORM-এর কোড চমৎকার লেখে — দেখতে পরিষ্কার, চলেও। কিন্তু ভুলগুলো ঠিক সেখানে, যেখানে কোড দেখে SQL বোঝা যায় না:

AI-এর ORM কোড বা migration মানার আগে — চেকলিস্ট

• SQL লগ চালু করে দেখেছি কয়টি query যায়, আর সংখ্যাটি ডেটার আকারের সাথে বাড়ে কি না
• তৈরি SQL-এর EXPLAIN দেখেছি; দরকারি index (বিশেষত foreign key-তে) আছে
• নমুনা ডেটায় ফল মিলিয়েছি: অর্ডারহীন গ্রাহক (LEFT JOIN), NULL আর ডুপ্লিকেট সারি ঠিক আছে
• migration-এ কোনো DROP, নাম বদল বা NOT NULL থাকলে তা expand–contract-এ ভাঙা হয়েছে, আর staging-এ বাস্তব আকারের ডেটায় সময় মেপেছি
• API আর কমান্ডের নাম নিজের ORM-এর সংস্করণের ডকুমেন্টেশনে মিলিয়েছি