Provisioning a DB for Testing - RodrigoMattosoSilveira/EnterpriseRemoteSystems GitHub Wiki

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.

1. 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"

2. Apply the full ERS migration chain Run:

DB_PATH="$DISPOSABLE_DB" ./scripts/db-migrate.sh

Expected 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

4. 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

5. 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-run

Do not edit the exported CSV first.

6. 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

7. 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 default

Expected:

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.csv

Condensed 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-run

The 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.