Expand the kvdb -> SQL migration itest to cover the full post-migration
startup behavior, not just the initial data copy and SQL assertions.
Verify that bbolt startup is blocked once kvdb files are deprecated,
that deleting the SQL database reruns the migration successfully, and
that older litd binaries still fail to start against deprecated kvdb
files.
Also add ordered blocker checks for the deprecated kvdb files so the
test shows startup fails first on accounts.db, then session.db, and
finally rules.db as earlier files are removed.
Close the process exit signal before forwarding litd startup errors from
the wait goroutine. This lets the harness observe that the process has
already exited even when no receiver is currently ready on the error
channel.
Use a non-blocking send for the captured process error so failed startup
paths do not hang the goroutine while holding back log finalization or
process exit handling.
This will be needed for the upcoming commit which adds itest coverage
of deprecated kvdb databases.
Mark the legacy kvdb stores as deprecated once the kvdb -> SQL
migration commits successfully. This prevents normal bbolt startup
from reopening accounts.db, session.db, or rules.db after their data
has already been migrated.
Add explicit deprecation checks to the three kvdb store open paths and
provide migration-only constructors that can still reopen deprecated
files when the SQL database is deleted or downgraded and the migration
must be rerun.
Use store-specific tombstones for the deprecation markers and add
tests that verify deprecated stores are rejected while migration
reruns continue to work.
Update the `sqldb/v2` dependency in go.mod to the published version, and
update the litd code to adhere to the new changes in the `sqldb/v2`
package.
Given that the official `sqldb/v2` package is now used, we can also
remove the `sqldb/v1` dependency from the go.mod file, as it is no
longer used in the codebase.
Add a store test that verifies that Accounts groups invoices and
payments by account ID and does not leak linked data across accounts
when using the store.Accounts function.
Add the ListAllAccountInvoices & ListAllAccountPayments queries to the
sqlcmig6 package, to mimic the sqlc queries present before the kvdb to
sql migration is added to prod.
Optimize SQL account listing by preloading linked invoices and payments
for all accounts in bulk.
Before this change, Accounts() queried ListAllAccounts and then did two
extra queries per account (ListAccountInvoices/ListAccountPayments),
which scales poorly as account count grows.
Add ListAllAccountInvoices and ListAllAccountPayments queries, group
their rows by account_id in memory, and marshal each account from the
preloaded data. Keep conversion logic shared through
marshalDBAccountWithLinkedData to preserve behavior between
single-account and list-account paths.
This reduces query count from 1 + 2N to 3 and improves list-path
performance without changing external semantics.
This commit implements an itest kvdb -> SQL migration itest. The
intention of the itest is to verify that the kvdb -> SQL migration flow
works for a litd node which has data inserted to the bbolt database.
To verify that, the minimum amount of data required to trigger the full
migration flow is inserted into the bbolt database, which is one object
to each database file. Those objects are:
* One account - accounts.DB file
* One session - session.db file
* One action - rules.db file
As the respective unit tests for each migration extensively tests that
data of all forms for each database file can successfully be migrated,
the itest only focuses on testing that the full migration flow works,
and leaves the responsibility of data variation coverage to the
respective unit test.
The test is executed in different steps, and uses RPCs to seed and
validate migration fixtures:
1. Start a node with a bbolt backend.
2. Insert one account, one session and one action via RPC.
3. Snapshot the inserted objects via RPC.
4. Restart with the configured SQL backend to trigger migration.
5. Query objects again via RPC.
6. Compare the new objects to the pre-migration snapshot.
7. Assert the migrated objects in SQL via direct queries, to verify that
it's actually the SQL database that contains the migrated objects.
The next commit that adds the kvdb to sql code migration will need to
initialize the accounts kvdb DB.
This commit exports that struct so that it can be referenced outside of
the accounts package.
When the kvdb to sql migration is initially introduced, we will want to
ensure that it is only run under dev builds during the testing phase.
We therefore introduce the functionality to have separate dev
migrations, which are only included in a separate migration stream that
is used only in dev builds.
Note that these dev migrations are currently not included in the
`sqlc.yaml` file, to ensure that the main sqlc models doesn't include
the dev migrations.
The upcoming kvdb to sql code migration will be added to as part of the
`sqldb/v2` migration stream. However, since the kvdb to sql migration
will need to use the migration functions present in the `accounts`,
`firewalldb`, and `session` packages, the migration will need to
referernce those packages. That would lead to a circular dependency
though if the migration stream was defined in the `db` package, as those
packages need to import the `db` package.
To avoid this, we introduce a new `migstreams` package that
contains the migration streams, and ensure that the `db` package doesn't
import the `migstreams` package.
In upcoming commits, we will introduce a new migration stream package
that will need to reference the db package, as well as the accounts,
session and firewalldb package in future commits. To avoid circular
dependencies, we therefore introduce a new migration stream that unit
tests can use, in order to avoid having to import the new migration
stream package.
In upcoming commits, other packages than the `db` package will need to
be able to access the `SqlSchemas`. This commit exports it in
preparation for those changes
As no code path uses the sqlc.UpdateAccountAliasForTests query, now that
migrations tests have been updated to use the sqlcmig6 version, we can
remove the query from the sqlc package. As this query is only intended
to be used for testing, it is beneficial to not expose it to the rest of
the codebase to avoid accidental usage in the future.
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.
In order to be able to use the custom queries with the
`sqlcmig6.Queries`, we assert at compile time that `sqlcmig6.Queries`
implements the `CustomQueries` interface.
This commit introduces the `sqlcmig6` package, which at the time of this
commit contains the same queries and models as `sqlc` package.
Importantly though, once the kvdb to sql migration is made available in
production, the `sqlcmig6` package will not change, as it is intended
to represent the sql db as it was at the time of the migration.
The sqlcmig6 package is therefore intended to be used in the kvdb to sql
migration code, as it is will always be compatible with the sql database
when all sql migrations prior to the kvdb to sql migration are applied.
When additional sql migrations are added in the future, they may effect
the `sqlc` package in such a way that the standard `sqlc` queries and
models aren't compatible with kvdb to sql migration code any longer.
By preserving the `sqlcmig6` package, we ensure that the kvdb to sql
migration code can always use the same queries and models that were
available at the time of the migration, even if the `sqlc` package
changes in the future.
Note that the `sqlcmig6` package have not been generated by `sqlc` (the
queries and models are copied from the `sqlc` package), as it is not
intended to be changed in the future.
As the legacy `NewTestPostgresDB` function is no longer used and has
been removed, it no longer makes sense to have a `V2` suffix on the
`NewTestPostgresV2DB` function. This commit renames it to
`NewTestPostgresDB`, to indicate that this function now replaces the
legacy function.
As we've now switched over to using sqldb v2 for most of the db objects,
we can remove a lot of deprecated code that's no longer used in the litd
project. This commit removes that code.
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.
Previous commits had forgotten to add the `ListAllKVStoresRecords` query
to the `firewalldb.SQLKVStoreQueries` interface. As that is required to
make the query useable when defining the `sqldb/v2`
`TransactionExecutor` for the `firewalldb` package, this commit
adds it to the interface.
As we will change the `accounts`, `session` & `firewalldb` packages to
use the `sqldb/v2` package, we need to make those packages use the
`sqldb/v2` `PostgresStore` when setting up their test postgres
databases, instead of `litd`'s own `PostgresStore` version.
In order to enable that functionality, we add a new helper function that
creates a `PostgresStore` using the `sqldb/v2` package, in addition to
helper function that creates a `PostgresStore` using the `litd`
version.
Once we have shifted all of `litd`'s code to use the `sqldb/v2`
definition, we will remove the `litd` version.
The upcoming implementation of `sqldb/v2` will extensively create
a `Queries` object on the fly. To make more intuitive how to create
the queries object for specific database types, we introduce a
`NewForType` helper method.
This also mimics how `tapd` creates the `Queries` object, and in order
not let `litd` have it's own definition of how `Queries` object are
created on the fly, the upcoming `sqldb/v2` usage will utilize this
helper method.
The `sqldb/v2` package now provides a definition for the `BackendType`
type. As useage of `sqldb/v2` requires useage of that type, we update
`litd` to use the `BackendType` definition from `sqldb/v2`, instead of
it's own definition.
A core component of `sqldb/v2` useage, is that the package allows and
requires that the callsite defines a `sqldb.MigrationStream` that will
be run during the initialization of the `sqldb/v2 database instance.
The `sqldb.MigrationStream` defines the exact sql migrations to run,
as well as additional code migrations will be run after each individual
migration version.
This commit introduces the core definition of the migration stream for
`litd`, and will be further exteded in upcoming commits that will
introduce kvdb to sql code migration.
Note that as of this commit, as no part of the `litd` codebase uses the
`sqldb/v2` database instances, this migration stream is not yet
used.
In upcoming commits, we will introduce support for sqldb/v2 in Lightning
Terminal, in order to support code migrations. This is needed, so that
we can ensure that the kvdb to sql migration is run exactly after an
exact sql migration version, and not after all sql migrations have been
executed. The reason why that's important is that sql table definition
may change with future sql migrations, while the kvdb to sql migration
will remain the same and always expect the same table definition.
Therefore, if the kvdb to sql migration is run after all sql migrations,
it may fail due to a table definition mismatch.
This commit adds the sqldb/v2 dependency to `litd`, so that we can
implement it's usage and execution of the kvdb to sql migration
correctly in the upcoming commits.
NOTE: currently the sqldb/v2 dependency hasn't been shipped in any
lnd release, so this dependency currently a forked version of
sqldb/v2.
