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 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.
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.
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.
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.
- 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.
In the upcoming kvdb to SQL migration of the actions store, we need to
simulate in tests that two or more accounts have colliding account
aliases for the first 4 bytes of the alias. In order to allow creation
of such accounts, we need to be able to update the alias of an account
in tests, and this commit adds the a SQL query enabling this
functionality.
Note that the `UpdateAccountAliasForTests` query is only intended for
use in tests and should not be used in production code.
Rename the session_id to group_id in kvstores table in the SQL store, to
better represent how the field is actually used.
Note that this is a breaking change, and would normally require a new
migration. But as the SQL store is not used in production, and only
enabled under the dev build flag, we can rename it without a new
migration, as there's no users of the SQL store in production.
During the upcoming upcoming migration of the firewall database to SQL,
we need to be able to check all kvstores records in the SQL database,
to validate that the migration is successful in tests.
This commits adds a query to list all kvstores records, which enables
that functionality.
Here, we manually define some queries for the actions store. We do this
so that we can manually build the "SELECT" and only add "WHERE" clauses
that are actually needed for the query and hence ensure that available
indexes are used.
In this commit we define the schema for the `actions` table along with
various queries we will need for interacting with the table. NOTE: we
will also add some of our own queries manually in commits to follow.
In preparation for the migration from kvdb to SQL, we update the results
of the ListAllAccounts query. After the migration has been implemented,
we will test that the result off all accounts in the SQL database
is the same as the result of the fetching all accounts in the kvdb.
By ordering the SQL query's result by account id, we ensure that all
accounts are returned in the same order as they are returned by the
kvdb.
This commit updates:
- LND
- pool
- loop
- taproot-assets
- faraday
- lighting-node-connect
- aperture
- lndclient
- btclog
We start using the new btclog v2 library and the associated breaking
changes in the lnd/build package.
With this commit, we deprecate the `--remote.lit-maxlogfiles` and
`--remote.lit-maxlogfilesize` options and introduce new logging options
under the `--remote.lit-logging` namespace.
Finally, the LND update introduced a new `MaxBlocksMinedPerTest`
variable in the `lntest` package that we now need to override in order
for our itests to pass.
Replace any named UNIQUE indices in the accounts tables and replace with
named ones. This is for a future where we want to be able to edit these
indices without having to drop the table.
It is fine for us to just edit these tables since these are not
available in "prod" yet.
This commit adds the boilerplate code we will need in order to start
using SQL backed stores (namely sqlite and postgres) for our DB backend.
NOTE that this has been copied from the taproot-assets repo.
This commit also contains the sqlc.yaml file, the `make sqlc` command
and the script for generating sqlc code. This must be done in this
commit as the script only works if there are queries to generate from.
