Permalink
10000
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 5 commits
- 22 files changed
- 3 contributors
Commits on Apr 28, 2025
-
build(deps): bump the production-dependencies group across 1 director…
…y with 2 updates (#3941) Bumps the production-dependencies group with 2 updates in the / directory: [github.com/google/cel-go](https://github.com/google/cel-go) and [google.golang.org/grpc](https://github.com/grpc/grpc-go). Updates `github.com/google/cel-go` from 0.24.1 to 0.25.0 - [Release notes](https://github.com/google/cel-go/releases) - [Commits](google/cel-go@v0.24.1...v0.25.0) Updates `google.golang.org/grpc` from 1.71.1 to 1.72.0 - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](grpc/grpc-go@v1.71.1...v1.72.0) --- updated-dependencies: - dependency-name: github.com/google/cel-go dependency-version: 0.25.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: production-dependencies - dependency-name: google.golang.org/grpc dependency-version: 1.72.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: production-dependencies ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
-
build(deps): bump packaging (#3940)
Bumps the production-dependencies group in /docs with 1 update: [packaging](https://github.com/pypa/packaging). Updates `packaging` from 24.2 to 25.0 - [Release notes](https://github.com/pypa/packaging/releases) - [Changelog](https://github.com/pypa/packaging/blob/main/CHANGELOG.rst) - [Commits](pypa/packaging@24.2...25.0) --- updated-dependencies: - dependency-name: packaging dependency-version: '25.0' dependency-type: direct:production update-type: version-update:semver-major dependency-group: production-dependencies ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Commits on May 22, 2025
Commits on Jun 8, 2025
-
build(deps): bump golang from 1.24.2 to 1.24.4 (#3983)
Bumps golang from 1.24.2 to 1.24.4. --- updated-dependencies: - dependency-name: golang dependency-version: 1.24.4 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Commits on Jun 13, 2025
-
SQLite: Coerce jsonb columns to json before returning to Go code (#3968)
* SQLite: Coerce jsonb columns to json before returning to Go code This one follows up the discussion in #3953 to try and make the `jsonb` data type in SQLite usable (see discussion there, but I believe that it's currently not). According the SQLite docs on JSONB [1], it's considered a format that's internal to the database itself, and no attempt should be made to parse it elsewhere: > JSONB is not intended as an external format to be used by > applications. JSONB is designed for internal use by SQLite only. > Programmers do not need to understand the JSONB format in order to use > it effectively. Applications should access JSONB only through the JSON > SQL functions, not by looking at individual bytes of the BLOB. Currently, when trying to use a `jsonb` column in SQLite, sqlc ends up returning the internal binary data, which ends up being unparsable in Go: riverdrivertest.go:3030: Error Trace: /Users/brandur/Documents/projects/river/internal/riverinternaltest/riverdrivertest/riverdrivertest.go:3030 Error: Not equal: expected: []byte{0x7b, 0x22, 0x66, 0x6f, 0x6f, 0x22, 0x3a, 0x20, 0x22, 0x62, 0x61, 0x72, 0x22, 0x7d} actual : []byte{0x8c, 0x37, 0x66, 0x6f, 0x6f, 0x37, 0x62, 0x61, 0x72} Diff: --- Expected +++ Actual @@ -1,3 +1,3 @@ -([]uint8) (len=14) { - 00000000 7b 22 66 6f 6f 22 3a 20 22 62 61 72 22 7d |{"foo": "bar"}| +([]uint8) (len=9) { + 00000000 8c 37 66 6f 6f 37 62 61 72 |.7foo7bar| } Test: TestDriverRiverSQLite/QueueCreateOrSetUpdatedAt/InsertsANewQueueWithDefaultUpdatedAt The fix is that we should make sure to coerce `jsonb` columns back to `json` before returning. That's what this pull request does, intercepting `SELECT *` and wrapping `jsonb` columns with a `json(...)` invocation. I also assign `json` and `jsonb` a `[]byte` data type by default so they don't end up as `any`, which isn't very useful. `[]byte` is consistent with the default for `pgx/v5`. [1] https://sqlite.org/jsonb.html * Make SQLite json/jsonb values `json.RawMessage` instead of `[]byte` This in response to code review feedback, it's a little more correct to make json/jsonb values `json.RawMessage` instead of `[]byte`. The former is a form of the latter, but better represents that the value is meant to be JSON. * Introduce `Selector` interface for generating column expressions This is response to code review feedback, add a new `Selector `interface whose job it is to provide an engine-agnostic way of generating output expressions for when selecting column values with `SELECT ...` or `RETURNING ...`. This is exclusively needed for SQLite for the time being, which uses it to wrap all output `jsonb` column values with a call to `json(...)` so that values are coerced to a publicly usable format before being returned. [1] #3968 (comment) * Make selectors internal to the `compiler` package This is based on original code review feedback that I'd misread initially. The selector interface doesn't need to be an outside package for any reason (it's used only internal to the compiler), and this lets us improve it somewhat by taking a full `*Column` struct rather than having to make it a `dataType string` (because `Column` is internal to `compiler` and it would otherwise introduce dependency cycles).
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v1.29.0...main