Open
Conversation
- Add StellarAddress type with sql.Scanner/driver.Valuer for automatic conversion between string addresses (G.../C...) and 33-byte BYTEA - Update accounts table: stellar_address TEXT -> BYTEA - Update transactions_accounts table: account_id TEXT -> BYTEA
- Use StellarAddress type for Get, Insert, Delete operations - Convert []string to [][]byte for BatchGetByIDs ANY() clause - Handle mixed BYTEA/VARCHAR in IsAccountFeeBumpEligible query
- Convert addresses to []byte for BatchInsert UNNEST($11::bytea[]) - Use raw []byte instead of pgtype.Text for BatchCopy
- Pass StellarAddress type which implements driver.Valuer for auto-conversion
- Test nil, valid, and error cases for both Scan and Value - Test roundtrip conversion preserves address
- Fix IsAccountFeeBumpEligible to use separate EXISTS checks instead of UNION (avoids type mismatch between BYTEA and VARCHAR columns) - Update test fixtures to use types.StellarAddress for BYTEA columns - Use types.StellarAddress for scanning account_id from transactions_accounts
This is the first step in converting the operations_accounts table to use BYTEA storage for account IDs, matching the pattern already used by transactions_accounts.
All account_id columns now use BYTEA storage format, so the string case handling for TEXT columns is no longer needed.
All account_id columns now use BYTEA format, so the conditional conversion logic is no longer needed. Always use AddressBytea.
Both operations_accounts and transactions_accounts now use BYTEA for account_id, so the field is no longer needed in the config.
Convert addresses to BYTEA format using AddressBytea.Value() when copying to operations_accounts, matching the transactions pattern.
Convert accountAddr to BYTEA format in HasOperationForAccount query since operations_accounts.account_id is now BYTEA.
- operations_test.go: Use AddressBytea type for scanning account_id - accounts_test.go: Convert address to BYTEA in INSERT statement - test_utils.go: Use AddressBytea directly (already has Value() method)
- Change SQL query to use UNNEST($9::bytea[]) instead of text - Convert addresses to []byte using AddressBytea.Value()
- Use AddressBytea type for scanning account_id in both BatchInsert and BatchCopy test verification - Use AddressBytea when inserting test accounts
Update migration to use BYTEA type for 7 account_id columns: - account_id - signer_account_id, spender_account_id - sponsored_account_id, sponsor_account_id - deployer_account_id, funder_account_id
Helper function to convert nullable address strings to bytes for BYTEA insert operations. Returns nil for invalid/empty addresses.
Update the StateChange struct to use AddressBytea type for account_id field to match the BYTEA database column type.
Convert 7 account_id columns from text arrays to bytea arrays: - account_id (required) uses AddressBytea.Value() - 6 nullable columns use pgtypeBytesFromNullStringAddress helper
Convert 7 account_id columns from pgtype.Text to raw []byte: - account_id (required) uses AddressBytea.Value() - 6 nullable columns use pgtypeBytesFromNullStringAddress helper
Convert accountAddress parameter to AddressBytea for BYTEA column query.
accounts, transactions_accounts: Store account_id as BYTEAaccount_id fields as BYTEA
There was a problem hiding this comment.
Pull request overview
This pull request converts storage of account_id fields from TEXT to BYTEA in the database. The change optimizes storage and query performance for Stellar addresses by storing them in their native 33-byte binary format (1 version byte + 32 raw key bytes) rather than as 56-character StrKey strings.
Changes:
- Introduced
AddressByteaandNullAddressByteatypes with SQL Scanner/Valuer interfaces for encoding/decoding between StrKey strings and BYTEA storage - Updated database migrations to change
account_idcolumns from TEXT to BYTEA in accounts, transactions_accounts, operations_accounts, and state_changes tables - Modified data access layer to convert addresses to/from BYTEA when inserting or querying
- Updated tests to use valid Stellar addresses generated from keypairs instead of hardcoded placeholder strings
Reviewed changes
Copilot reviewed 42 out of 42 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/indexer/types/types.go | Added AddressBytea and NullAddressBytea types with Scan/Value implementations for BYTEA conversion |
| internal/indexer/types/types_test.go | Added comprehensive tests for AddressBytea Scan/Value/String methods and roundtrip conversion |
| internal/db/migrations/*.sql | Updated CREATE TABLE statements to use BYTEA for all account_id columns |
| internal/data/accounts.go | Updated queries to convert string addresses to BYTEA; refactored IsAccountFeeBumpEligible to use OR instead of UNION |
| internal/data/transactions.go | Added address-to-BYTEA conversion for transactions_accounts link table insertions |
| internal/data/operations.go | Added address-to-BYTEA conversion for operations_accounts link table insertions |
| internal/data/statechanges.go | Added conversion for account_id and nullable address fields to BYTEA |
| internal/data/query_utils.go | Added pgtypeBytesFromNullAddressBytea helper for nullable address conversions |
| internal/utils/sql.go | Added NullAddressBytea helper function for creating nullable address values |
| internal/services/ingest_test.go | Replaced hardcoded test addresses with valid addresses from keypairs |
| internal/serve/graphql/resolvers/*.go | Updated resolvers to convert AddressBytea to string for GraphQL responses |
| internal/indexer/*.go | Updated to handle AddressBytea type conversions |
| internal/integrationtests/infrastructure/backfill_helpers.go | Updated queries to use AddressBytea for account address parameters |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…let-backend into accountid-bytea-txns
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.
What
This pull request converts storage of account_id fields from TEXT to BYTEA in the database. The change optimizes storage and query performance for Stellar addresses by storing them in their native 33-byte binary format (1 version byte + 32 raw key bytes) rather than as 56-character StrKey strings.
Changes:
Introduced AddressBytea and NullAddressBytea types with SQL Scanner/Valuer interfaces for encoding/decoding between StrKey strings and BYTEA storage
Updated database migrations to change account_id columns from TEXT to BYTEA in accounts, transactions_accounts, operations_accounts, and state_changes tables
Modified data access layer to convert addresses to/from BYTEA when inserting or querying
Updated tests to use valid Stellar addresses generated from keypairs instead of hardcoded placeholder strings
Why
Optimizes storage while not sacrificing query latency
Known limitations
N/A
Issue that this PR addresses
Closes #490 #491 #493