Fix: register bigint as an 8-byte integer to fix RangeError on bigint columns - #30
Merged
Merged
Conversation
otegami
marked this pull request as draft
July 31, 2026 12:26
otegami
force-pushed
the
fix/duckdb-bigint-range-error
branch
from
July 31, 2026 12:48
b0a4771 to
5e4456e
Compare
otegami
marked this pull request as ready for review
July 31, 2026 12:55
kou
reviewed
Aug 1, 2026
Comment on lines
+27
to
+28
| User.create!(bigint: 2 ** 62) | ||
| assert_equal(User.new(id: 1, bigint: 2 ** 62), |
Member
There was a problem hiding this comment.
Why do we need these changes? I think that both of 2 ** 32 and 2 ** 64 are int64 range. (They are out of int32 range.)
Member
Author
There was a problem hiding this comment.
I've reverted this change because it was not necessary, as you mentioned.
I changed it because I initially wanted a test value that needed 8 bytes.
But both are out of the int32 range and within the int64 range, so the change was unnecessary.
| private | ||
| def initialize_type_map(m) | ||
| super | ||
| m.register_type(/\A(?:bigint|int8)\b/i) do |sql_type| |
Member
There was a problem hiding this comment.
Could you add a comment why we need this?
The CI has failed about DuckDB since 2026-06-21 as follows. ``` Error: test_bigint_active_record(TestType): ActiveModel::RangeError: 4294967296 is out of range for ActiveModel::Type::Integer with limit 4 bytes ``` ref: https://github.com/red-data-tools/activerecord-adbc-adapter/actions/runs/27942838514/job/82680163239?pr=29#step:10:1 ### Cause DuckDB 1.5.4 started reporting `xdbc_type_name`. It was nil in DuckDB 1.5.3, so no cast type was resolved at all. ref: duckdb/duckdb#23110 So `new_column_from_field` now resolves a cast type from `xdbc_type_name`. We don't override the type map, so that lookup goes like this. 1. `BIGINT` matches AbstractAdapter's only integer entry, `register_class_with_limit m, %r(int)i, Type::Integer`. 2. `register_class_with_limit` takes the limit from `extract_limit`, which only reads digits inside `(...)`. 3. `BIGINT` has no `(...)`, so the limit is nil and `Type::Integer` falls back to `DEFAULT_LIMIT = 4`. 4. 4 bytes allows up to `1 << (4 * 8 - 1)`, so writing `2 ** 32` raises. PostgreSQL is in the same state for the same reason. Its ADBC driver reports `typ.typname`, which is `int8` for both `bigint` and `bigserial`, and `int8` has no `(...)` either. SQLite is safe by accident: our DDL emits `bigint(8)`, so step 2 finds the 8. ### Fix Register `bigint` and `int8` as 8 bytes, like PostgreSQLAdapter does for `int8`. Both names mean 8 bytes on all three backends. An explicit `limit:` still wins, so `t.bigint :x, limit: 4` keeps resolving to 4 bytes in SQLite. `\b` keeps PostgreSQL's `int8range` and `_int8` out.
otegami
force-pushed
the
fix/duckdb-bigint-range-error
branch
from
August 3, 2026 11:06
5e4456e to
3ae5738
Compare
otegami
commented
Aug 3, 2026
otegami
left a comment
Member
Author
There was a problem hiding this comment.
Thank you for reviewing. I've just addressed all of them.
Member
|
Thanks. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CI has failed about DuckDB since 2026-06-21 as follows.
ref: https://github.com/red-data-tools/activerecord-adbc-adapter/actions/runs/27942838514/job/82680163239?pr=29#step:10:1
Cause
DuckDB 1.5.4 started reporting
xdbc_type_name. It was nil in DuckDB 1.5.3,so no cast type was resolved at all.
ref: duckdb/duckdb#23110
So
new_column_from_fieldnow resolves a cast type fromxdbc_type_name. Wedon't override the type map, so that lookup goes like this.
BIGINTmatches AbstractAdapter's only integer entry,register_class_with_limit m, %r(int)i, Type::Integer.register_class_with_limittakes the limit fromextract_limit, whichonly reads digits inside
(...).BIGINThas no(...), so the limit is nil andType::Integerfallsback to
DEFAULT_LIMIT = 4.1 << (4 * 8 - 1), so writing2 ** 32raises.PostgreSQL is in the same state for the same reason. Its ADBC driver reports
typ.typname, which isint8for bothbigintandbigserial, andint8has no
(...)either.SQLite is safe by accident: our DDL emits
bigint(8), so step 2 finds the 8.Fix
Register bigint and int8 as 8 bytes, like PostgreSQLAdapter does for
int8. Both names mean 8 bytes on all three backends. An explicit 'limit:'
still wins, so
t.bigint :x, limit: 4keeps resolving to 4 bytes in SQLite.