Since the `assertMigrationResults` now expects a `*sqlcmig6.Queries`
instance to be passed directly into the function, there is no need to
create a separate *sqlcmig6.Queries instance than the one created when
the `*sqlcmig6.TxExecutor` transaction is created. We therefore
refactor the execution of the `assertMigrationResults` function to be
called in the scope of that transaction.
Due to this change, there's also no longer a need to return the `*SQLDB`
instance from the `makeSQLDB` helper function.
As the firewalldb package kvdb to sql migration tests creates `sqlc`
models to assert the migration results, we will need to update those
call sites to instead use the `sqlcmig6` models instead, in order to
be compatible with the `sqlcmig6.Queries` queries.
However, since we can't update the `SQLDB` methods to use `sqlcmig6`
models as params, we need to update the test code assertion to instead
use the `sqlc.Queries` object directly instead of the `SQLDB` object.
This makes it easy to swap that `sqlc.Queries` object to a
`sqlcmig6.Queries` object in the commit that updates the firewalldb
package to use the `sqlcmig6` package for the kvdb to sql migration.
rename `sqlStore` to `store` in the firewalldb sql migration test file,
to make the name shorted. This is done in preparation for future commits
which will lengthen the lines where `sqlStore` is used, which otherwise
would make the lines exceed the 80 character limit.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
If there are no RPCParamsJson set for an action, the value is
represented differently in KVDB vs SQL.
In the SQL DB, empty RPCParamsJson are represented as nil, while they
are represented as an empty array in the KVDB version. Therefore, we
need to override the RPCParamsJson in that scenario, so that they are
set to the same representation when a KVDB and an SQL action is
compared.
If the user has deleted their session.db file, but kept their
rules.db file, there can exist privacy mapper pairs that point to a now
deleted session ID. Such pairs should be ignored during the migration,
as they are cannot be used anymore.
This commit updates the migration to handle this case.
If the user has deleted their session.db file, but kept their
rules.db file, there can exist kv entry values that point to a now
deleted session ID. Such kv entries should be ignored during the
migration, as they are cannot be used anymore.
This commit updates the migration to handle this case.
This commit introduces the migration logic for transitioning the
actions store from kvdb to SQL.
Note that as of this commit, the migration is not yet triggered by any
production code, i.e. only tests execute the migration logic.
This commit adds an `accountStore` and a `rootKeyStore` arg the database
population functions of the kvdb to SQL migration tests of the
firewalldb.
As an action can be linked to an account, we need to enable simulation
of that in the migration tests of the actions store. In order to create
the accounts to link the actions to, we need to create the accounts in
the account store, which therefore requires passing the `accountStore`
to database population functions of the migration tests.
As the kvdb to SQL migration also will update the migrated actions to
not only store the 4 byte short ID of the action's corresponding
macaroon, but to it's full 8 byte root key ID. This requires the
migration function has access to all of lnd's 8 byte root key IDs, and
the migration function will therefore be change to accept a [][]byte
arg containing all of lnd's root key IDs.
As we can't access a full lnd instance in the migration unit tests, we
need to create a mock instance that simulates the root key store, and
this commit therefore adds mock `rootKeyStore` struct which is also
passed to the database population functions of the migration tests.
This `rootKeyStore` struct can be used to generate dummy root key IDs
when creating simulated actions in the migration tests.
In preparation for the kvdb to SQL migration of the actions store, this
commit adds an `actions` field to the expected result of the migration
tests. Once the migration is implemented, this field will be used to
validate that the migrated actions match the expected results.
This commit introduces the migration logic for transitioning the
privacy mapper store from kvdb to SQL.
Note that as of this commit, the migration is not yet triggered by any
production code, i.e. only tests execute the migration logic.
This commit removes speculative comments from the firewalldb migration
docs that forecast future implementations. Such comments can create
confusion for developers looking at the current code base without
knowing our plans how the migration will be further developed.
Currently, the migration tests for firewalldb only migrates the kv
stores. In future commits, we will also migrate the privacy mapper
and the actions in the firewalldb,. Before this commit, the expected
results of the migrations tests could only be kv records, which will not
be the case when we also migrate the privacy mapper and the actions.
Therefore, we prepare the migration tests to expect more than just kv
records. This commit introduces a new type of `expectedResult` type
which the prep of the migration tests will use, which can specify more
than just one type of expected result.
As the firewalldb migration will include more than just the migration
of the kvstore data, we rename the migration tests that only migrate
the kvstore data to make it clearer which tests only focus on migrating
kv entries.
This commit introduces the migration logic for transitioning the
kvstores store from kvdb to SQL.
Note that as of this commit, the migration is not yet triggered by any
production code, i.e. only tests execute the migration logic.
