The blockchain-deposit arm of the transaction search, as a view.
Rows are on-chain credits landing on a ledger account's token account that do
not correspond to any known platform transaction. Assembled inline, the
12-arm transaction UNION serialises to ~124KB; RDS Proxy refuses to parse a
statement over 16KB and pins the client session to its database connection
for the rest of that session. Behind a view the arm's own body is a table
reference.
Nothing is left in transaction-services/queries/blockchainDeposit.ts but the
shared transactionScalarConditions, which are plain predicates on this
view's own projected columns — customer_id is customer.external_id and
signature is solana_transaction.signature, the same value the view also
projects as id.
Both things that used to be caller-supplied moved in here:
The known-signature EXCLUSION set (knownSignaturesSql), which was ~5.9KB
of the ~7.4KB UNION when it was inlined on every search. It could not move
while its sub-selects were scoped by the caller's customerId; correlating
each branch on the row's own customer replaced that parameter (see
knownSignaturesSql for why the scoping is semantic, not just an
optimisation).
The MOVEUSD SPL mint pin on the solana_account_transaction scan, which the
view resolves from token itself.
dbmate owns the DDL: the body below is mirrored by its own migration, exactly
as the tables here mirror theirs.
securityInvoker is required, not cosmetic — every underlying table has RLS
enabled, and without it the view would run with the owner's row visibility and
silently bypass the querying role's policies.
The blockchain-deposit arm of the transaction search, as a view.
Rows are on-chain credits landing on a ledger account's token account that do not correspond to any known platform transaction. Assembled inline, the 12-arm transaction UNION serialises to ~124KB; RDS Proxy refuses to parse a statement over 16KB and pins the client session to its database connection for the rest of that session. Behind a view the arm's own body is a table reference.
Nothing is left in
transaction-services/queries/blockchainDeposit.tsbut the sharedtransactionScalarConditions, which are plain predicates on this view's own projected columns —customer_idiscustomer.external_idandsignatureissolana_transaction.signature, the same value the view also projects asid.Both things that used to be caller-supplied moved in here:
knownSignaturesSql), which was ~5.9KB of the ~7.4KB UNION when it was inlined on every search. It could not move while its sub-selects were scoped by the caller'scustomerId; correlating each branch on the row's own customer replaced that parameter (seeknownSignaturesSqlfor why the scoping is semantic, not just an optimisation).solana_account_transactionscan, which the view resolves fromtokenitself.dbmate owns the DDL: the body below is mirrored by its own migration, exactly as the tables here mirror theirs.
securityInvokeris required, not cosmetic — every underlying table has RLS enabled, and without it the view would run with the owner's row visibility and silently bypass the querying role's policies.