Binding a newtype id in a raw sql statement

[jimbrankelly]

I need to run a raw query that uses a parameter that needs to reference a field that is a newtype id.
My id definition is:struct CartId(Uuid)

I tried defining a to_sql() function that converts the CartId to a string but that doesn't work as sqlite is storing the field as a byte array in the database.

Any ideas?

[felipebridge]

SQLite doesn't have a native UUID type, so a UUID column ends up being either TEXT (if something wrote uuid.to_string()) or BLOB (16 raw bytes, if something wrote uuid.as_bytes()) — there's no way to tell just from the schema, it's whatever the original INSERT used. Since your existing rows are BLOB, converting CartId to a string in to_sql() doesn't match: SQLite happily stores the string as its own value, but it'll never equal the 16-byte blob already sitting there, so any WHERE-clause lookup against existing rows silently returns nothing.

Fix is to bind the raw bytes instead: something like self.0.as_bytes().to_vec() (or &[u8; 16], depending on what your to_sql() return type expects) rather than .to_string(). That reproduces exactly how the existing BLOB values were written, so equality comparisons in the query actually match.

If whatever crate handles the Uuid↔sqlite conversion here already ships a blob-based impl for the bare Uuid type (a lot of them do, since it's the more compact/canonical choice for SQLite), you might not even need a custom impl on CartId at all — a transparent newtype wrapper that just delegates to Uuid's existing impl would pick up the same BLOB encoding for free instead of hand-rolling to_sql().

[jimbrankelly]

Thank you for your insight. I tried casting my cart_id to a uuid but toasty didn't like that. Ill try your suggestion of using as_bytes. Thanks again.

…

On Sun, Sep 20, 2026, 10:35 AM Felipe Bridge ***@***.***> wrote: SQLite doesn't have a native UUID type, so a UUID column ends up being either TEXT (if something wrote uuid.to_string()) or BLOB (16 raw bytes, if something wrote uuid.as_bytes()) — there's no way to tell just from the schema, it's whatever the original INSERT used. Since your existing rows are BLOB, converting CartId to a string in to_sql() doesn't match: SQLite happily stores the string as its own value, but it'll never equal the 16-byte blob already sitting there, so any WHERE-clause lookup against existing rows silently returns nothing. Fix is to bind the raw bytes instead: something like self.0.as_bytes().to_vec() (or &[u8; 16], depending on what your to_sql() return type expects) rather than .to_string(). That reproduces exactly how the existing BLOB values were written, so equality comparisons in the query actually match. If whatever crate handles the Uuid↔sqlite conversion here already ships a blob-based impl for the bare Uuid type (a lot of them do, since it's the more compact/canonical choice for SQLite), you might not even need a custom impl on CartId at all — a transparent newtype wrapper that just delegates to Uuid's existing impl would pick up the same BLOB encoding for free instead of hand-rolling to_sql(). — Reply to this email directly, view it on GitHub <#411?email_source=notifications&email_token=BK43ZHXSIDWW2TULWEQNSHT5P72M5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4DSMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18528922>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BK43ZHTWCEXZDLJTSXRQDSD5P72M5AVCNFSNUABJKJSXA33TNF2G64TZHMYTEMBQGUZTINRVGA5UI2LTMN2XG43JN5XDWMJQHAYTKMZTHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BK43ZHWRNVFLOTYL3ZVG2D35P72M5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4DSMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BK43ZHVWYBLGYCVLOGZ34YT5P72M5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4DSMRSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[pikaju]

I think this belongs on the Toasty repository

[jimbrankelly]

Yes, indeed it does. I posted there and received a prompt response.