refactor: clean up migrations

[shotexa]

Overview

Remove all migrations and only create new ones that creates database with the latest state (data loss is not accounted)

Screenshots

Checklists

Pre-submit checklist:

• Self-reviewed the diff
• New code has proper comments/documentation/tests
• Any changes not covered by tests have been tested manually
• The README files are updated
• If new libraries are included, they have licenses compatible with our project
• If there is a db migration altering existing tables, there is a proper migration test

Pre-merge checklist:

• Commits have useful messages
• Review clarifications made it into the code

[atala-dev]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors
✅ ACTION	actionlint	1		0
✅ REPOSITORY	dustilock	yes		no
✅ REPOSITORY	git_diff	yes		no
✅ REPOSITORY	grype	yes		no
⚠️ REPOSITORY	kics	yes		93
✅ REPOSITORY	syft	yes		no
✅ REPOSITORY	trivy-sbom	yes		no
⚠️ REPOSITORY	trufflehog	yes		1
✅ SQL	sql-lint	1		0
⚠️ YAML	prettier	2		1
✅ YAML	v8r	2		0
✅ YAML	yamllint	2		0

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[github-actions]

Unit Test Results

325 tests   - 3   324 ✔️  - 3   38s ⏱️ +3s
  45 suites  - 3       1 💤 ±0 
  45 files    - 3       0 ❌ ±0 

Results for commit 3177bb5. ± Comparison against base commit 15e6865.

This pull request removes 3 tests.

io.iohk.atala.prism.node.migrations.V19MigrationSpec ‑ Migrating to version db.migration.V19 should work
io.iohk.atala.prism.node.repositories.migrations.V6MigrationSpec ‑ Migrating to version V6 should work
io.iohk.atala.prism.node.repositories.migrations.V8MigrationSpec ‑ Migrating to version V8 should work

♻️ This comment has been updated with latest results.

[EzequielPostan]

thank you @shotexa
linter complains aside, the migration looks correct. I only added a question out of curiosity

[EzequielPostan]

Just curious, I guess this unified migration comes from pg_dump output, but I didn't see this loop in any previous migration file. Do you know what created the loop?

[shotexa]

Check V13__add_ledger_data_to_protocol_events.sql

-- + public_keys table
-- in this table, there is no BYTEA value we could use for default transaction_id,
-- we neither have a hex encoded BYTEA we could use, we will use the function found
-- here: https://dba.stackexchange.com/questions/22512/how-can-i-generate-a-random-bytea
create function random_bytea(p_length in integer) returns bytea language plpgsql as $$
declare
  o bytea := '';
begin
  for i in 1..p_length loop
    o := o||decode(lpad(to_hex(width_bucket(random(), 0, 1, 256)-1),2,'0'), 'hex');
  end loop;
  return o;
end;$$;
-- it is not the most efficient but it will be enough for our case

[shotexa]

TLDR: there is a loop but you might have missed it due to how it is formatted, it is a bit hard to notice in previous migration.

[EzequielPostan]

Oh, that explains it. Thanks

[shotexa]

@EzequielPostan If everything looks correct please approve so I can merge it

[EzequielPostan]

Thank you @shotexa
Please check the linter complain before merging