Proposal: Support for SQLite Generated Columns

[remimarsal]

Introduction

SQLite supports Generated Columns, which are columns whose values are automatically computed based on other columns in the same row. This is a powerful feature for enforcing data consistency and simplifying application logic by delegating computations to the database.

Currently, swift-structured-queries does not have a first-class way to represent these columns:

• A property representing a generated column cannot be marked as a standard column because the library would attempt to include it in INSERT and UPDATE statements, resulting in a "read-only column" error from SQLite.
• Marking it as @Ephemeral is also incorrect, as the column does exist in the database and should be included in SELECT statements.

Proposed Solution

Introduction of a new property macro, @GeneratedColumn, to be used within a @Table macro.

@Table
struct Event {
  let id: UUID
  var startAt: Date
  var duration: TimeInterval

  @GeneratedColumn
  var endAt: Date
}

This macro would signal to the query builder that endAt is a column that exists for reading (SELECT) but should be ignored for writing (INSERT, UPDATE).

The @GeneratedColumn macro would be parameter-less since the database schema definition (including the GENERATED ALWAYS AS ... expression) lives outside the Swift type definitions, typically in SQL migration files. The macro's only role is to inform the query builder of the column read-only nature.

Let me know what you think, I've been experimenting with the macro and it seems to work as expected. I'm happy to open a PR !

[stephencelis]

@remimarsal This all sounds great to us! A few thoughts:

• Can you share your branch so we could take a look?
• What do you think of adding this as an overload of the @Column macro instead?

  @Column(generated: true)

• I think we'd consider adding a parameter to distinguish between .virtual and .stored...while we might not use them right away, they would be helpful if we ever need to introduce logic around them, like for migration helpers.

[remimarsal]

Adding it as an overload of @Column is even better, it does make the API more cohesive. I went ahead and combined both suggestions on this branch.

[stephencelis]

@remimarsal This is looking really good! I think it's worth moving to a PR if you think it's ready. We can provide more feedback there and hopefully get things merged soon!