Tag + search filter combines with OR instead of AND

Nobody has started this yet — be first.

Business impact

Combining a tag filter with a search query (e.g. "my go-tagged bookmarks about concurrency") returns a flood of irrelevant results -- anything tagged go or merely matching the query -- instead of the narrow intersection the user asked for. Filtering is the core value of a bookmark manager once someone has more than a couple dozen links; a filter that gets less precise the more criteria you add teaches users not to trust it.

Problem

Store.List joins the active filter clauses together before appending them to the query. When both tag and q are given, the join currently produces OR semantics -- everything matching either condition -- instead of requiring both to match the same row.

Current behavior

GET /bookmarks?tag=go&q=concurrency returns bookmarks that only match one of the two filters, not just the ones matching both.

Expected behavior

tag and q, when both present, combine with AND: only bookmarks matching both conditions come back. Each filter alone (tag-only or query-only) is unaffected.

Steps to reproduce

Seed: "Go Concurrency Patterns" (tags go, programming), "Python Concurrency Patterns" (tags python, programming), "Go Testing Guide" (tags go, testing), "Unrelated Recipe" (tags cooking). curl -s "http://localhost:8081/bookmarks?tag=go&q=concurrency"

Expected: exactly 1 result ("Go Concurrency Patterns")

Actual: more than 1 result

Why this matters

The project's own design intentionally builds the WHERE-clause list and the parameter-args slice "in lockstep" -- the single line combining the per-filter clauses with a boolean operator is exactly where a naive implementation goes wrong, without any type error to catch it. Parameterization itself is untouched and still correct.

Suggested approach

Look at the line in Store.List where clauses gets joined into the final WHERE text, and think about what "matches the tag AND matches the query" means as a boolean combination.

Acceptance criteria

tag=go&q=concurrency returns only rows matching both.
tag=go alone and q=concurrency alone are unaffected.
A combined filter matching nothing returns zero rows, not the union of each filter's individual matches.

Verification

go test ./practicetickets/... -run TestTicket02 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/filter-combines-with-or

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/filter-combines-with-or

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Bookmark Manager — Parameterized Filtering Done Right

A small, real bookmark-saving API whose entire reason for existing is teaching the habit of building tag/search SQL filters with parameterized queries -- clause list and argument slice built in lockstep -- instead of string-concatenated SQL, even in an app "nobody" is attacking.

Fork on GitHub

Download

Setup

Bookmark Manager — Parameterized Filtering Done Right

git clone <your-fork>
cd go/bookmark_manager
cp .env.example .env   # optional, defaults already work
docker compose up --build   # postgres (host 5433) + app (host 8081)

The app waits for Postgres to become reachable, then applies (idempotent -- safe to rerun on every startup) before serving traffic.

migrations/0001_init.sql

curl http://localhost:8081/healthz
# {"status":"ok"}

docker run -d --name bm_test_pg -e POSTGRES_PASSWORD=postgres \
  -e POSTGRES_DB=bookmarks_test -p 15433:5432 postgres:16-alpine

go test ./practicetickets/... -run TestTicket01 -v   # a single ticket
./practice_tickets_run.sh                             # all 10, clean pass/fail summary table