SIENTIAPDE-1972: localiza criacao das tabelas de predicao (pandas to_sql), adiciona schema/table_name ao contrato NATS e fixa cert bucket aprovado
This commit is contained in:
PedroHMCosme
@@ -63,7 +63,7 @@ Mongo `sientia`:
|
||||
|
||||
### Escrita hoje (Laborious)
|
||||
- Escrita OPC **direta** via `asyncua` (`laborious/activities/opc.py` → `opc_repository.write_data` → `node.write_value`).
|
||||
- Status de escrita é gambiarra: sobrescreve `prediction_confidence` com sentinelas (`12`=erro escrita, `14`=sessão ruim; PI=`13`) em `process_confidence`. Predições persistidas em Postgres `predictions_schema.predictions` (`model_id, prediction, prediction_confidence, response_time, prediction_status, timestamp, created_at, comments`).
|
||||
- Status de escrita é gambiarra: sobrescreve `prediction_confidence` com sentinelas (`12`=erro escrita, `14`=sessão ruim; PI=`13`) em `process_confidence`. Predições persistidas em Postgres (`model_id, prediction, prediction_confidence, response_time, prediction_status, timestamp, created_at, comments`) via **pandas `to_sql`** (schema/tabela por-modelo, criados por inferência do DataFrame; `predictions_schema.predictions` é só fixture de teste).
|
||||
- Payload de escrita já contém: `server_id`, `addr`, `value`, `data_type`, `tag_type`, `model_id`, `model_name`, `timestamp`.
|
||||
|
||||
## 5. Arquitetura do Gateway (Abordagem B — engines por capacidade)
|
||||
@@ -123,13 +123,16 @@ Laborious publica, Gateway consome. Core NATS, subject `opc.write` (avaliar `opc
|
||||
```json
|
||||
{ "msg_id":"uuid","server_id":"server1","addr":"ns=2;i=5","value":42.0,
|
||||
"data_type":"float","tag_type":"prediction","model_id":"1","model_name":"m1",
|
||||
"schema":"sientia_data","table_name":"predictions_<model>",
|
||||
"timestamp":"2026-07-13T12:00:00Z","write_timestamp":true,"write_quality":false }
|
||||
```
|
||||
`schema`+`table_name` são necessários porque a tabela de predição é **por-modelo** — o Gateway usa-os para o `UPDATE` da coluna `write_status` (ver C3).
|
||||
|
||||
### C3 — Coluna de status de escrita (Postgres, tabela de predições) ⭐ autoritativo em topics.md
|
||||
Nova coluna no DDL padrão de predições (ex.: `write_status` + opcional `write_status_detail`/`write_status_at`). Em **escrita OPC**, o **Gateway** grava o status vinculando por **`timestamp` + `model_id`**. Em **escrita PI Web API**, o **Laborious** grava. Substitui as sentinelas `12/13/14` em `prediction_confidence`.
|
||||
- **Onde:** schema/tabela de predição são **config por modelo** (`input_data['schema']`/`['table_name']` no Laborious) — não há tabela única fixa. A coluna faz parte do **DDL padrão** de predições; homologar no schema gerenciado pelo Flyway (**`sientia_data`**). Migração via `Aignosi/sientia-dataops-database-migrations` (`.sql` versionado, Job Helm hook), backward-compatible.
|
||||
- **Provisionamento (CONFIRMADO):** as tabelas de predição são **criadas dinamicamente por modelo**. Logo a coluna `write_status` entra no **template de criação** dessas tabelas (novas) + **backfill** (`ALTER TABLE ... ADD COLUMN IF NOT EXISTS`) nas existentes. Flyway cobre a migração de backfill/tabelas conhecidas; o template dinâmico precisa passar a incluir a coluna. Localizar onde o DDL de criação vive (Laborious/`sientia_do` Postgres/migrations) — ver §17.
|
||||
- **Provisionamento (LOCALIZADO):** **não há DDL/template** — as tabelas são criadas por **pandas `DataFrame.to_sql(if_exists='append')`** em `sientia_do/temporal/activities/postgres.py:439-464`, com o **schema inferido das colunas do DataFrame**. Logo: (a) **tabelas novas** ganham `write_status` automaticamente quando o DataFrame de predições do Laborious passar a incluir a coluna (trabalho do 1975); (b) **tabelas existentes** precisam de **backfill** `ALTER TABLE <schema>.<table> ADD COLUMN IF NOT EXISTS write_status ...` — como são dinâmicas/por-modelo, a migração Flyway enumera as tabelas existentes (ex.: via `information_schema`) ou usa migração repetível/callback.
|
||||
- **Fluxo de gravação:** o Laborious grava a linha de predição (via `to_sql`) com `write_status` default (ex.: `pending`/null); depois o Gateway faz `UPDATE <schema>.<table_name> SET write_status=... WHERE timestamp=... AND model_id=...`. Por isso a mensagem NATS (C2) carrega `schema`+`table_name` (a tabela é por-modelo).
|
||||
|
||||
### C4 — GRPC leitura on-demand
|
||||
```
|
||||
@@ -224,17 +227,16 @@ Nota de plataforma: os docs air-gapped diziam *"do not include RabbitMQ/NATS unl
|
||||
- **Broker = NATS** (Core NATS agora; §8). Definido pelo brief/Vitor.
|
||||
- **Nome da branch:** renomeada para `feature/SIENTIAPDE-1972-...` ✅.
|
||||
|
||||
**Resolvidas (docs/código + Vitor):**
|
||||
- **Migração = Flyway** — repo `Aignosi/sientia-dataops-database-migrations`, schema `sientia_data` (substituiu Alembic/SQLAlchemy). Coluna = `.sql` versionado (V2+), Job Helm hook.
|
||||
- **Bucket de certs = `sientia-dataops`** (decisão Vitor). Escrita dos certs do 1569 migra p/ esse bucket. (§7)
|
||||
**Resolvidas (docs/código + Vitor + Bruno):**
|
||||
- **Migração = Flyway** — repo `Aignosi/sientia-dataops-database-migrations`, schema `sientia_data`. Coluna = `.sql` versionado, Job Helm hook.
|
||||
- **Bucket de certs = `sientia-dataops`** (aprovado por Bruno). Ação: migrar a escrita dos certs do 1569 p/ esse bucket + policy (impl, não decisão). (§7)
|
||||
- **JOIN do 1974 = chave `tag_id`** (o pipeline referencia `tag_id`; `(server+address)` é ambíguo sob multi-nome). (§15)
|
||||
- **`metadata` = campo (objeto) na tag, default vazio** (decisão Vitor); tags de teste com `metadata: {}`. (§4)
|
||||
- **Tabelas de predição = pandas `to_sql` (sem DDL/template)** — coluna nova via DataFrame do Laborious (tabelas novas) + backfill `ALTER TABLE` (existentes). (§6 C3)
|
||||
|
||||
**Em aberto (precisam de humano):**
|
||||
1. **Provisionamento do NATS no air-gapped:** subchart/versão/sizing/network policy (a *escolha* já é NATS). (§8) — **plataforma/Bruno**
|
||||
2. **Escrita dos certs 1569 → `sientia-dataops`:** ajuste no app 1569 + policy do user do frontend p/ o bucket DataOps. (§7) — **plataforma**
|
||||
3. **Template de criação das tabelas de predição:** confirmado que são dinâmicas por modelo → coluna `write_status` no template + backfill das existentes. Localizar onde vive o DDL de criação (Laborious/`sientia_do`/migrations) e definir o backfill. (§6 C3) — **Vitor / dono do repo de migrations** (ou localizo no código ao escrever o spec do 1975)
|
||||
4. **Chamador do GRPC on-demand:** quem chama `ReadTag` e modelo de auth. — **Vitor**
|
||||
2. **Chamador do GRPC on-demand:** quem chama `ReadTag` e modelo de auth. — **Vitor**
|
||||
|
||||
**Adiada por design (nós):**
|
||||
- **Durabilidade da escrita:** Core NATS agora; reavaliar JetStream (TTL curto) se houver perda real em restart.
|
||||
|
||||
Reference in New Issue
Block a user