DataTalksClub / DataTalksClub/faq

[FAQ]

Open Beginner friendly
#409 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

faq-proposal
Dominant language
Python
Stars
7
Forks
19
Avg merge
3d 20h
Merged PRs (30d)
9

Description

Course

ai-dev-tools-zoomcamp

Question

Why does swapping SQLite for PostgreSQL in Agent Relay (Homework 3, Question 4) break every authenticated request with a syntax error?

Answer

The starter's database.py has a context manager, immediate_transaction(), that opens every transaction with a raw connection.exec_driver_sql("BEGIN IMMEDIATE"). BEGIN IMMEDIATE is SQLite-specific syntax — it reserves SQLite's writer lock up front — and it's invalid on PostgreSQL.

This isn't a minor edge case: immediate_transaction() wraps authenticate(), create_task(), claim_one(), heartbeat(), and commit_terminal(). Once RELAY_DATABASE_URL points at Postgres, essentially every authenticated endpoint fails immediately with a syntax error, even though the rest of the codebase (SQLAlchemy models, psycopg as a dependency, no other raw SQL) is already database-agnostic by design, per SPEC.md.

Fix: only issue BEGIN IMMEDIATE when the backend is actually SQLite; let PostgreSQL use SQLAlchemy's normal autobegin transaction instead.

def _is_sqlite(database_url: str) -> bool:
return database_url.startswith("sqlite")

@contextmanager
def immediate_transaction():
connection = engine.connect()
session = Session(bind=connection, expire_on_commit=False, autoflush=True)
try:
if _is_sqlite(DATABASE_URL):
connection.exec_driver_sql("BEGIN IMMEDIATE")
yield session
session.commit()
finally:
session.close()
connection.close()

SQLite behavior is unchanged — it still gets the writer-lock reservation. One thing to know going in: on SQLite, BEGIN IMMEDIATE's writer lock was doing double duty — it also happens to be why concurrent task claims never overlap. Postgres's default autobegin has no equivalent, so this fix alone doesn't restore that guarantee; it needs SELECT ... FOR UPDATE SKIP LOCKED on the claim query for full parity, which is exactly the seam SPEC.md itself flags for a future PostgreSQL port. Worth knowing if your test suite includes a concurrent-claims test — it may need to be skipped against Postgres until that follow-up hardening is in place.

Checklist
  • I have searched existing FAQs and this question is not already answered
  • The answer provides accurate, helpful information
  • I have included any relevant code examples or links

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the proposed FAQ against the repository's existing FAQ entries, then verify the technical explanation against the referenced database.py and SPEC.md from ai-dev-tools-zoomcamp. Done means the question and answer are accurate, readable, non-duplicative, and ready to publish as an FAQ entry.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql, python, sqlite
Domain
databases, documentation
Issue type
Documentation
Difficulty
1/5
Estimated time
Under an hour
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.