Skip to content

feat: add bigint column type support and update dependencies#2950

Open
ArnabChatterjee20k wants to merge 10 commits intomainfrom
big-int
Open

feat: add bigint column type support and update dependencies#2950
ArnabChatterjee20k wants to merge 10 commits intomainfrom
big-int

Conversation

@ArnabChatterjee20k
Copy link
Copy Markdown
Member

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Apr 1, 2026

Greptile Summary

This PR introduces BigInt column type support for the tablesDB feature, adding a new bigint.svelte column form, wiring up create/update API calls, and adding a buildPayload helper that serializes BigInt values to strings before sending to the API. The SDK dependency is also bumped to pick up the ColumnBigint model.

  • P1 — min/max not normalized before API call (bigint.svelte lines 22–27, 37–46): xdefault is passed through normalizeBigInt() but min and max are sent as raw JavaScript numbers, inconsistent with the bigint-typed ColumnBigint model fields and broken for values beyond Number.MAX_SAFE_INTEGER.
  • Unrelated pnpm-lock.yaml changes: The project uses bun exclusively (per AGENTS.md); modifications to pnpm-lock.yaml appear to be a local side-effect and should be reverted.

Confidence Score: 4/5

Mostly safe but the min/max normalization gap in bigint.svelte should be fixed before merging to avoid incorrect API calls for large constraint values.

One P1 finding: min and max are passed as JS number to the SDK while xdefault is correctly normalized to bigint, which will silently send wrong types for values above Number.MAX_SAFE_INTEGER. The unrelated pnpm-lock.yaml diff should also be reverted. All other changes are well-structured.

src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/bigint.svelte — normalization inconsistency for min/max

Vulnerabilities

No security concerns identified. The buildPayload string-serialization approach for BigInt avoids JSON serialization issues without exposing any injection surface.

Important Files Changed

Filename Overview
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/bigint.svelte New BigInt column creation/edit form — min/max are not normalized to BigInt before the SDK call (unlike xdefault), and normalizeBigInt can throw for float inputs.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/store.ts Adds buildPayload helper that converts BigInt column values to strings before API submission; logic looks correct for the string-serialization approach.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/columns/types/string.svelte Adds bigint case that falls through to parseInt — acceptable per prior team discussion; placeholder and type union updated correctly.
pnpm-lock.yaml Modified by running pnpm in a bun-only project — unexpectedly strips libc entries from many platform-specific package resolutions; should not be changed.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/+page.svelte Adds bigint to the column-type display block and correctly includes Models.ColumnBigint in the cast union.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/edit.svelte Routes row update through buildPayload to serialize BigInt fields before sending to API.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/rows/editRelated.svelte Both related-row update paths now use buildPayload for consistent BigInt serialization.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/spreadsheet.svelte Spreadsheet inline-edit now serializes BigInt columns via buildPayload; bigint icon mapping added correctly.
src/routes/(console)/project-[region]-[project]/databases/database-[database]/table-[table]/columns/store.ts Registers the BigInt column option with correct type, icon, and create/update handlers.
src/lib/helpers/faker.ts Adds fake BigInt generation via faker.number.bigInt().toString(); string form is consistent with how BigInt values are serialized for the API.

Reviews (6): Last reviewed commit: "updated the type" | Re-trigger Greptile

- Updated bigint column type handling in the database table columns.
- Refactored input components to use InputText for bigint values with validation.
- Improved parsing and error handling for bigint inputs in string representation.
- Adjusted type definitions to include bigint in various contexts.
- Added bigint type to the Columns type definition.
- Updated bigint input handling in the bigint.svelte component, replacing InputText with InputNumber for better user experience.
- Enhanced data binding and validation for bigint values, including min, max, and default settings.
- Adjusted column value handling in various components to accommodate bigint type.
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Apr 9, 2026

Tip:

Greploop — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.

Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.

tableId: page.params.table,
rowId: row.$id,
data: row
data: buildPayload(columns, row as Record<string, unknown>)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why unknown here instead of a typed row?
Do we not know the shape,
Can't we define a type?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants