Skip to content

Liquibase: separate out test-data context from others #1257

Open
@php-coder

Description

@php-coder

At this moment test-data context follow the same rules as others. Let's extract it and put it aside as it's different than others because it's applied to an in-memory database that is always created from scratch.

Advantages of the current approach:

  • test-data is treated similarly to prod-data: the migrations that modify data also applied to test data. This might help to catch mistakes in such migrations on early stages. But it can't catch them all and that's what Build scripts: check database upgrade before deploy #383 should cover.

Disadvantages of the current approach:

  • Adding a new test record in a table becomes difficult over time because a table structure is scattered between many migrations. This means that in order to identify what columns a table have, we need to look on all migrations that touched this table or we need to run a server and inspect a table in H2 console.
  • The similar applies to test data -- it's hard to predict what ID a new record would have because it requires to inspect all migrations.
  • copying&pasting isn't reliable as a table structure might have changed between migrations
  • when we add another one test record to a table, we can append it into an existing migration but after that a migration filename might get outdated. In this case, we can rename a file but it might be unsafe (as Liquibase remembers filenames).
  • because there is no way to distinguish changes of test-data from other types of change, we can't configure Danger to complain when migrations that touche non-test data have been modified.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ADR/neededA decision has been made and it needs to be documentedenvironment/testIssue affects only test environmentrefactoring

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions