notify

Database csatorna

A tartós database notification csatorna.

Ez az alcsomag adja a notify durable, lekérdezhető csatornáját: importáld, amikor egy notificationnek perzisztált, olvasható előzményt akarsz adni, nem csak egy elküldött mailt vagy egy élő push-t.

import notifydatabase "github.com/gp-system/notify/database"

Database

A notify/database (+notify/database/bunx) egy notification durable, lekérdezhető oldala: minden Databasable notification egy notifications táblába kerül, így a recipiens egy perzisztált, „notification inbox" mintát kap (a modul Laravel-notifications-szerű része) bármi más felett, ami elsül. A dbx-ra épül, ugyanúgy, mint a kit többi perzisztencia-rétege.

store := notifydatabase.NewStore(pg.NewDB(pool))       // pgx
store := notifydatabasebunx.NewStore(bunDB)             // bun, a notify/database/bunx-on keresztül
channel := notifydatabase.NewChannel(store)

Record és Store

A Databasable notificationöket egy notifications táblába perzisztálja:

CREATE TABLE notifications (
    id           uuid        PRIMARY KEY,
    recipient_id text        NOT NULL,
    name         text        NOT NULL,
    payload      jsonb       NOT NULL DEFAULT '{}'::jsonb,
    read_at      timestamptz,
    created_at   timestamptz NOT NULL DEFAULT now()
);

Nincs notifiable_type oszlop (a kitnek nincs polimorf user-modellje, egy recipiens csak egy string id), nincs updated_at (a sorok csak read_at-et kapnak). A csatorna megköveteli a Recipient.ID-t; egy on-demand küldés (ID nélkül) hibázik ezen a csatornán: a Via-ban ezekhez csak a notify.ChannelMail-t nevezd meg.

A Store interfész az univerzális 90%-ot fedi: Insert, List (ListOptions{UnreadOnly, Limit, Offset}), CountUnread, MarkRead, MarkAllRead. Minden olvasás/frissítés explicit recipientID-t vár, így egy erre épülő handler sosem nyúlhat véletlenül másik recipiens sorába. A tényleges HTTP-inbox (response DTO-k, rbac.Identity.SubjectrecipientID guard) felépítése a saját modulod dolga: a kit a Store-ig megy, ugyanaz a határ, amit az outbox is húz a saját táblája köré.

Az NewChannel(store) egy Store-t csomagol egy notify.Channel-lé, amit a Hub dispatchol; ezen keresztül routolódik egy Databasable notification tartalma.

Nincs NOTIFY_* env config: a csatorna-engedélyezés maga a wiring; a Hub pontosan azokat a csatornákat tartalmazza, amit a belépési pont megkonstruál.

MemoryStore

store := notifydatabase.NewMemoryStore() // a teljes Store-t implementálja, az olvasó oldalt is

A MemoryStore egy test double: minden Store-metódust implementál, így egy termék Postgres nélkül tesztelheti az inbox-handlereit (listázás, olvasottá jelölés, olvasatlanok számolása). Párosítsd a notifydatabase.NewChannel(store)-dal tartalom-renderelési lefedettséghez egy Hub-ban, ugyanúgy, ahogy a mail.NewMemory() is helyettesíti a valódi mailert.

Migráció

A notifications tábla goose-migrációként érkezik, ugyanabban a mintában, mint az outbox.MigrationSQL: a notifydatabase.MigrationSQL a séma forrása a csomagban, és az add notification első futása írja be a projekt migrations/ könyvtárába, a következő szabad timestampen. Az inboxot birtokló service indítása előtt futtasd le: go run ./cmd/migrate up (lásd Migrációk).

Kapcsolódó oldalak

  • Áttekintés: a Hub, a Notification és a mail-csatorna.
  • Broadcast: ennek a durable csatornának az élő push-párja.
  • dbx: pgx és dbx: bunx: az executorok, amikre az NewStore és a bunx-adapter épül.
Copyright © 2026