docs(deploy): restore the dump rather than seeding fresh, with the measured difference

This commit is contained in:
LincPay
2026-08-15 16:40:43 +05:30
parent bbf226506b
commit 351da2f67d
+39
View File
@@ -215,6 +215,45 @@ none of that risk. **Recommendation: keep the jar.**
- [ ] The browser network tab shows `/api/v1/udyam/...` calls returning 200, not HTML
- [ ] `UDYAM_JWT_SECRET` is not the committed default
## Restoring the demo database — do this rather than seeding fresh
Verified on 2026-08-15: a freshly seeded database and the working demo database are
**not the same demo**. The seeder writes the plan, which is 129 enterprises; the working
database carries 263, along with three years of real Agmarknet prices that only a
`DATAGOV_API_KEY` and a long backfill can produce.
| | Restored dump | Fresh boot + bootstrap |
|---|---|---|
| Enterprises | 263 | 129 |
| RED | 50 | 14 |
| Trip-wires firing | **6** | **5** — TW-05 silent |
| Open alerts | 344 | 70 |
| Real Agmarknet rows | 8,292 | 0 |
TW-05 reads a price anomaly against a three-year seasonal mean. Generated series are
calibrated to sit near the real data's typical z of 0.44, so they legitimately do not
breach a 1.5 threshold — the trip-wire is not broken on a fresh database, it simply has
nothing anomalous to find.
```bash
createdb -U postgres UdyamLinc_DEMO
pg_restore -U postgres -d UdyamLinc_DEMO --no-owner --no-privileges udyamlinc_demo.dump
```
Then start the jar. The seeder is idempotent and will leave the restored book alone.
`--no-owner --no-privileges` matters when the demo server's Postgres role is not
`postgres`; without them the restore fails on every `ALTER ... OWNER TO` line.
Verify:
```sql
select count(*) from enterprise; -- expect 263
select source, count(*) from market_signal group by source; -- expect an AGMARKNET row
```
The sequence below is the fallback for a server that has no dump to restore.
## Populating a fresh database — the demo sequence
The seeder writes the portfolio, the ledger and the forecasts. It does **not** write