Generalization of @Table and @Column from StucturedQueries

[tevelee]

First off, I want to say that this project is an exciting and noble effort! The structured query system you’re building is a fantastic addition to Swift, and I appreciate the thoughtfulness behind @Table, @Column, and their ability to generate Hashable query representations, render them into SQL, and generate Draft structures.

As I was exploring the design through the video series, I couldn’t help but notice that @Table and @Column are effectively specialized versions of a more general concept: serialization. Specifically, these macros allow for:

• Custom naming – By default, the property name is used, but it can be customized.
• Serialization strategies – Some types, like Date, are not natively representable in SQL, so strategies like .iso8601 or .epoch are applied.

This closely mirrors how Codable works in Swift, where field names and encoding/decoding strategies can be customized. Given this similarity, I’d like to propose a generalization.

A more general @Serializable / @Field macro could provide customization for model and property naming, as well as serialization strategies. @Table could then extend this functionality by adding support for Draft structures and ensuring that fields are SQLRepresentable. For example, Date is not directly representable in SQL, so it requires a custom encoding/decoding strategy to convert it into a String or Int. Similarly, MySQL does not natively support boolean fields, so they require a coding strategy to convert them into TINYINTs, whereas JSON (via Codable) does support booleans natively.

I’m not suggesting a wholesale replacement or reimplementation of Codable, but rather encouraging a broader perspective on serialization—beyond just queries. The ability to define serialization strategies and model relationships could have broader applications beyond SQL, making this approach more flexible and reusable.

It’s a half-baked idea, but I still wanted to share it. Let me know what you think!

[mbrandonw]

Hi @tevelee, would it be possible for you to flesh out these ideas a bit more and provide some concrete ramifications of embarking on something like this? What do we have to gain by making @Table/@Column into a more general purpose serialization library? What are the "broader applications" you allude to? And do we not run the risk of coming out the other side with something that is just kind of average for a bunch of different things rather than really good for just one thing?

Right now we are only focused on SQL, and in particular SQLite, but we do have plans to make the library work equally well with MySQL and Postgres.

[tevelee]

I see. I'll build some prototypes and explore the idea on my own, see if it has merits. What I have in mind is the fusion of https://github.com/SwiftyLab/MetaCodable and StructuredQueries with an abstract representation of coding strategies. Just wanted to share my initial thoughts on broader use-cases of the system you're building.

[maximkrouk]

I just found a usecase for it, there is some json support in sqlite which is very handy for merging data from multiple tables. I'm not sure if it's better from the performance perspective than multiple quieries, however it's much more ergonomic.

Here is an example, it requires JSONDecoder adjustments to convert keys and dates from db values, probably some generic helper would be nice (tho keys could be converted with additional arguments for json_object function for example and maybe further improved with storing original names of Table properties in TableColumns)