sqlc is a tool that generates fully type-safe idiomatic code from SQL.
The result is Go code can then used execute the queries in the database.
The noraml flow looks like:
- The developer write some sql that will update the schema in the
database: new tables, indices, etc
- The developer updates the set of queries that will use the new schema.
- `sqlc` generates type-safe interfaces to those queries.
- The developer can then write application code that calls the methods
generated by sqlc.
The tool configuration needs to live in the repo's root and its name is
`sqlc.yaml`.
LND will support out of the box sqlite and postgres. The sql code needs to
be (almost) the same for both engines, so we cannot use custom functions
like `ANY` in postgres.
The SQLC config file needs to define what is the target engine, we will
set postgres but the generated code can be executed by sqlite too.
In some specific cases, we will `match and replace` some sql lines to be
sure the table definitions are valid for the targeted engine.
Currently `make lint` creates a new container each time it runs. We can
automatically delete these containers once linting is done by using the
--rm flag.
This commit adds a new build tag `integration` and removes the old tag
`rpctest` for clarity. Multiple unnecessary usages of `build !rpctest`
is also removed.
Since `go1.18` the runtime has a package that provides information about module
versions, version control information, and build flags embedded in executable
files built by the go command.
The new packages allows us to get information needed by the `version` command
without having to rely on `ldflags` set at build time.
This can be really helpful while debugging errors from people using custom
binaries. For example a build from master.
`rpc-check` is used in our CI pipeline to detect any difference
between the committed and the automatically generated rpc files.
Unfortunately, the current method only detects changes in the
already existing files and won't fail if `make rpc` generates
a totally new file.
`git status --porcelain` makes the trick, it returns a line for
each file that has been modified, created or deleted.
Instead of hard coding a commit to use for a binary tool that we use
during the build process, we now only use "go install" to install the
binaries and the golang builtin versioning system to pin the exact
version/commit we want to use in go.mod.
Recent gomobile versions are now building for the `xcframework`
packaging format instead of `framework`. This commit addresses
this by outputting to a `.xcframework` folder.
Since we don't really do anything with the errors we check in the itest
error whitelist but get a lot of failed Travis runs because of it, we
disable the check for the moment.
To fix an issue where the golang version would be picked up from the
host system if the docker-release command was used, we switch over to
using make inside of the container as well instead of feeding the
parameters into the release script manually.
We only pass in the flags that we might actually want to overwrite.
To fix an issue where the vendor.tar.gz in a release build had a
different hash if the mobile RPC stubs were in the mobile/ folder, we
clean those out first.
The culprit was the `google.golang.org/grpc/test/bufconn` package which
is currently only used in the mobile RPC stubs and nowhere else.
Therefore the vendor/module.txt was different when vendoring with the
generated mobile RPC stubs being around.
Now that we have a base docker image that has all our RPC compilation
dependencies installed, we can also run the mobile RPC compilation
there. This removes the need to install falafel and goimports on the
local machine.
