Repository navigation
Provisioning a DB for Testing
For Bite 32.7, the safest disposable target is a brand-new SQLite database file created from the current repository migrations, then used only for the importer dry-run. Use these steps from the repository root.
- Choose a disposable database path For example:
export DISPOSABLE_DB="$PWD/backend/data/bite327-portability-test.db"Remove any previous copy and its SQLite sidecars:
rm -f \
"$DISPOSABLE_DB" \
"$DISPOSABLE_DB-wal" \
"$DISPOSABLE_DB-shm"- Apply the full ERS migration chain Run:
DB_PATH="$DISPOSABLE_DB" ./scripts/db-migrate.shExpected end of output:\
✅ Migrations applied.
The script creates the SQLite file if it does not already exist and applies every checked-in *.up.sql migration. 3. Confirm the database exists Run:
ls -lh "$DISPOSABLE_DB"Then verify SQLite integrity:
sqlite3 "$DISPOSABLE_DB" "PRAGMA integrity_check;"Expected:
ok
- Use the disposable default Tenant For this portability test, you do not need to create another Tenant manually. The importer defaults to the canonical ERS Tenant: default
and its startup/reference-data seeding ensures that Tenant exists. You can confirm it after the importer initializes the database, or explicitly inspect it later with:
sqlite3 "$DISPOSABLE_DB" \
"SELECT id, code, name, active FROM tenants ORDER BY id;"The relevant row should be:
default|DEFAULT|Default Tenant|1
- Run the exported CSV through the importer in dry-run mode Assuming the CSV you downloaded from the UI is: ~/Downloads/ers-people-export.csv
run:
cd backend
go run ./cmd/import-people \
-db "$DISPOSABLE_DB" \
-file ~/Downloads/ers-people-export.csv \
-tenant-id default \
-dry-runDo not edit the exported CSV first.
- Evaluate the result You want output equivalent to:
People CSV dry-run report
Rows read: <number greater than 0>
Rows validated: <same number>
Rows inserted: 0
Errors: 0
PASS requires:
- Rows read > 0
- Rows validated = Rows read
- Rows inserted = 0
- Errors = 0
Because -dry-run runs the validation inside a transaction and rolls it back, no People should remain inserted in the disposable database. You can verify:
sqlite3 "$DISPOSABLE_DB" \
"SELECT COUNT(*) FROM people;"For a freshly created disposable DB, that should remain:
0
- Optional stronger test: perform a real import into the disposable database After the dry-run passes, you can go one step further and prove the file can actually be inserted. From backend/:
go run ./cmd/import-people \
-db "$DISPOSABLE_DB" \
-file ~/Downloads/ers-people-export.csv \
-tenant-id defaultExpected:
People CSV import report
Rows read: <number greater than 0>
Rows validated: <same number>
Rows inserted: <same number>
Errors: 0
Then verify:
sqlite3 "$DISPOSABLE_DB" \
"SELECT COUNT(*) FROM people;"and:
sqlite3 "$DISPOSABLE_DB" \
"SELECT COUNT(*) FROM person_tenant_memberships WHERE tenant_id = 'default';"Both counts should correspond to the imported People. For the manual promotion gate, however, the dry-run is sufficient. The real disposable import is useful if you want stronger confidence before promoting. 8. Delete the disposable database when finished Return to the repository root if necessary, then:
rm -f \
"$DISPOSABLE_DB" \
"$DISPOSABLE_DB-wal" \
"$DISPOSABLE_DB-shm"Also remove the exported CSV when you no longer need it because it contains sensitive personal and banking information:
rm -f ~/Downloads/ers-people-export.csvCondensed command sequence From the repository root:
export DISPOSABLE_DB="$PWD/backend/data/bite327-portability-test.db"
rm -f \
"$DISPOSABLE_DB" \
"$DISPOSABLE_DB-wal" \
"$DISPOSABLE_DB-shm"
DB_PATH="$DISPOSABLE_DB" ./scripts/db-migrate.sh
sqlite3 "$DISPOSABLE_DB" "PRAGMA integrity_check;"
cd backend
go run ./cmd/import-people \
-db "$DISPOSABLE_DB" \
-file ~/Downloads/ers-people-export.csv \
-tenant-id default \
-dry-runThe important detail is: do not use your Brazilian demo database as the target. A fresh disposable DB avoids the expected duplicate-identity collisions that would occur if you exported Serra Dourada People and then tried to re-import them into the same database.