[sql-6] accounts: SQL boilerplate and accounts schemas and queries #953
Conversation
ellemouton
added
no-changelog
ellemouton
force-pushed
the
sql6Accounts6
branch
from
6894b79 to
7cc11a4
Compare
ellemouton
force-pushed
the
sql6Accounts6
branch
from
7cc11a4 to
7ad8101
Compare
db/sqlc/models.go
Outdated
| Expiration time.Time | ||
| } | ||
|
|
||
| type AccountIndicy struct { |
There was a problem hiding this comment.
it's the return type that would be returned if we were to have a query such as "select * from account_indices"
but we only have "select value from account_indices where name = x", so this doesnt get used. But it is still generated
There was a problem hiding this comment.
I found it strange that it singularizes AccountIndicies to Indicy 😄, I think it uses https://github.com/jinzhu/inflection under the hood. ah, I think we should change it to account_indices then it gets converted to AccountIndex
There was a problem hiding this comment.
indeed! cool - updated :)
ellemouton
force-pushed
the
sql6Accounts6
branch
from
7ad8101 to
268cd5b
Compare
db/sqlc/models.go
Outdated
| Expiration time.Time | ||
| } | ||
|
|
||
| type AccountIndicy struct { |
There was a problem hiding this comment.
I found it strange that it singularizes AccountIndicies to Indicy 😄, I think it uses https://github.com/jinzhu/inflection under the hood. ah, I think we should change it to account_indices then it gets converted to AccountIndex
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.
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.
ellemouton
force-pushed
the
sql6Accounts6
branch
from
268cd5b to
536b411
Compare
don't fear the large number of changed lines - this is mostly boilerplate and generated code
Fixes #956
Here, we add the set of account tables and queries we will need to implement the SQL version of the accounts store.
Since this is the first PR that makes use of sqlc, it also includes all the boilerplate code we need. The boiler plate code is copied from the
taproot-assetsrepo.While it would have been ideal to have a single PR that adds the boiler plate code and then a separate one for adding the accounts schemas, this is not possible due to the
make sqlccommand not working if no queries are defined.Context:
In our current KVDB store impl of the accounts store, we use an
AccountIDto refer to a unique account. It is an 8 byte slice that uniquely identifies an account. These 8 bytes are used by users (via CLI) to interact with a specific account AND these 8 bytes are also embedded into the caveat of the macaroon generated for interacting with the account so that when a request comes in, we can check the macaroon caveat to see if it is aimed at a specific account.In SQL land, it is standard to use an auto-incrementing ID (int64) to refer to records. So in our SQL implementation, we will use int64 IDs for accounts and any relations at the SQL level will refer to accounts using its int64 ID. However, we obviously want to remain backwards compatible with any existing accounts which use the old
AccountIDidentifier. And so what we will do here is to have both anid(int64) field and analias(BLOB NOT NULL UNIQUE) field which will contain the 8 byteAccountID. I've called italiasinstead oflegacy_idsince we can't really deprecate this field ever if we want to remain backwards compatible.Then, for any queries, we always query by
idat the SQL level since that is more idiomatic. So then at the CRUD level, we will first query theidlinked to analiasand then continue with the query from there.Reviewing:
If you'd like to see how this code is used (ie, the CRUD) then it might help to glance at #954 while reviewing this.
But to keep review load manageable, when reviewing this PR, try to just focus on correctness of the schemas and queries. We can always do minor tweaks to the queries later on if we realise things on the CRUD layer need to change.
Schemas and relations: