Reply Pilot Database
reply-pilot-db je samostatny PostgreSQL modul pro Reply Pilot. Nevystavuje
REST/JSON API; vystavuje samotny PostgreSQL server na sdilene Docker siti
reply-pilot-internal a lokalne na 127.0.0.1:${HOST_DB_PORT}.
Co modul resi
- persistentni ulozeni databazovych souboru na host path mimo kontejner
- PostgreSQL konfiguraci pres
conf/postgresql.conf - logovani do
logs/reply-pilot-db.log - verzovane Liquibase changelogy pres
scripts/reply-pilot-db-migrate.sh - automaticke spusteni Liquibase
validateaupdatepristartadeploy
Persistencni host path
Nejdulesitejsi parametr je HOST_DATA_DIR v .env.local nebo .env.server.
Tahle cesta urcuje, kam na hostu fyzicky spadnou PostgreSQL data. Proto data
preziji restart kontejneru i serveru.
Uvnitř kontejneru se PostgreSQL cluster inicializuje do PGDATA=/app/data/postgresql.
To je schvalne podadresar bind mountu, protoze oficialni PostgreSQL image
nepodporuje initdb primo do rootu mountpointu.
Migrace
Liquibase pouziva vlastni tabulky:
public.databasechangelogpublic.databasechangeloglock
Pri prvnim spusteni nad starsi databazi se puvodni public.schema_migrations
automaticky prevede do Liquibase historie, aby se uz aplikovane zmeny
nepoustely znovu. Nasledny changeset 0004 stary tracking table smaze.
Aktualni user table je:
public.app_user
Tabulka app_user ma zatim:
id BIGINT GENERATED BY DEFAULT AS IDENTITYlogin_key TEXT NOT NULLauth_user_id TEXT NOT NULL DEFAULT ''email TEXT NULLdisplay_name TEXT NOT NULL DEFAULT ''gmal_box_link TEXT NOT NULL DEFAULT ''created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
Dalsi migrace zavedly:
public.partypublic.party_personpublic.party_organizationpublic.contact_mechpublic.contact_mech_emailpublic.contact_mech_phonepublic.party_contact_mechpublic.party_relationshippublic.activity_typepublic.activitypublic.activity_emailpublic.activity_callpublic.activity_meetingpublic.activity_notepublic.activity_participantpublic.task_typepublic.taskpublic.task_jirapublic.task_jira_email_thread
Legacy tabulky public.company, public.company_contact a
public.communication_history byly po migraci na party/activity model
odstranene changesetem 0010.
Treti changeset pridava:
public.simple_auth_nonce
Tuto tabulku pouziva reply-pilot-app pro replay protection simple-auth
callbacku. Uklada pouzite rp_nonce a jejich expiraci.
Sesty changeset pridava:
public.email_replay_ai_prompt
Tuto tabulku pouziva reply-pilot-app pro spravu predpripravenych AI promptu,
ktere lze vybirat na strance odpovedi na e-mail.
Jedenacty changeset pridava task model:
public.task_typepublic.taskpublic.task_jirapublic.task_jira_email_thread
task je obecny root zaznam podobny activity. Aktualne ma jediny typ jira,
ulozeny v task_type.
task_jira drzi Jira-specific pole:
captiondescriptionjira_keystatusparty_iduser_idresolution
task_jira_email_thread navazuje task na jedno nebo vice emailovych vlaken pres
external_thread_id, protoze aktualni activity model zatim nema samostatnou
tabulku pro email thread.
Dvanacty changeset pridava:
public.party_organization.show_by_default BOOLEAN NOT NULL DEFAULT TRUE
show_by_default urcuje, jestli se firma ma bezne zobrazovat ve standardnich
listingu, odvozenych company lookupu a company search dokumentech. Primy detail
firmy zustava pristupny i kdyz je hodnota nastavena na FALSE.
Trinacty changeset rozsiril public.task_jira o:
feed BOOLEAN NOT NULL DEFAULT FALSEenlistment_table BOOLEAN NOT NULL DEFAULT FALSE
Oba atributy jsou lokalni metadata Jira tasku v Reply Pilotu. Pri vytvoreni
tasku maji vychozi hodnotu FALSE a meni se v editaci tasku.
Ctrnacty changeset pridava CME company tracking:
public.party_cme_matchpublic.party_cme_check_queue
party_cme_match drzi posledni znamy vysledek porovnani firmy proti CME
lookupu. Uklada technicky vysledek matchu (NO_MATCH, MATCHED,
AMBIGUOUS, ERROR), CME integration_state, volitelny cme_dodavatel_id,
dalsi metadata shody a cas posledni kontroly.
party_cme_check_queue je interní worker fronta pro firmy, ktere cekaji na CME
check. Umoznuje periodicky zpracovavat jen nove nebo starnouci firmy misto full
scanu cele tabulky party_organization.
Readonly preview user
Operacni skripty DB modulu umi po migracich sladit i volitelneho readonly
PostgreSQL uzivatele pro nahled do DB. Konfigurace je v .env.local nebo
.env.server:
DB_PREVIEW_USER_ENABLEDDB_PREVIEW_USER_NAMEDB_PREVIEW_USER_PASSWORD
Kdyz je DB_PREVIEW_USER_ENABLED=1, skripty vytvori nebo zapnou login a daji
mu CONNECT na databazi, USAGE na public a SELECT na vsechny aktualni i
budouci tabulky/sekvence v public. Kdyz je DB_PREVIEW_USER_ENABLED=0,
skripty roli prepnou na NOLOGIN, takze jde v produkci vypnout jen nastavenim.
Lokalni start
cd reply-pilot-db
cp .env.example .env.local
./scripts/reply-pilot-db-start.sh
reply-pilot-db-start.sh po readiness checku automaticky spusti Liquibase
validate a update. Stejne tak reply-pilot-db-deploy.sh. Rucni migracni skript zustava
zachovany a prime Liquibase prikazy lze volat pres
./scripts/reply-pilot-db-liquibase.sh.
Ověření
./scripts/reply-pilot-db-psql.sh -c '\dt public.*'
./scripts/reply-pilot-db-psql.sh -c 'select id, author, filename, orderexecuted from public.databasechangelog order by orderexecuted;'
./scripts/reply-pilot-db-liquibase.sh history
./scripts/reply-pilot-db-liquibase.sh rollback-count 1
Opakovane spusteni ./scripts/reply-pilot-db-migrate.sh musi nechat schema beze
zmen. Kazdy migrations/*.sql soubor ma presne jeden Liquibase changeset a
musi obsahovat explicitni --rollback.
Workflow při změně schema
Kdyz menis databazove schema:
- pridej Liquibase changeset do
reply-pilot-db/migrations/ - dopln novy soubor do
reply-pilot-db/migrations/db.changelog.xml - zajisti explicitni
--rollback - over migraci pres:
cd reply-pilot-db
./scripts/reply-pilot-db-liquibase.sh validate
./scripts/reply-pilot-db-liquibase.sh update
./scripts/reply-pilot-db-liquibase.sh rollback-count 1
./scripts/reply-pilot-db-liquibase.sh update
Pokud se meni activity/contact data model, aktualizuj i docs/activity-model.md
a přegeneruj souvisejici diagramy pres rp.