Support optional Draft fields for non-optional Table columns

[igorcamilo]

Problem

When using @Table with non-optional fields that have SQL DEFAULT values (like createdAt/updatedAt timestamps), the generated Draft type mirrors the Swift default — not the SQL default. This means the SQL DEFAULT clause never fires on insert.

Example

@Table
struct Entry: Identifiable {
  let id: Tagged<Entry, UUID>
  var createdAt: Date = now()
  var updatedAt: Date = now()
  var notes = ""
}

CREATE TABLE "entries" (
  "id" TEXT PRIMARY KEY NOT NULL DEFAULT (uuid()),
  "createdAt" TEXT NOT NULL DEFAULT (now()),
  "updatedAt" TEXT NOT NULL DEFAULT (now()),
  "notes" TEXT NOT NULL DEFAULT ''
) STRICT

The generated Draft inherits the Swift defaults:

// Expanded from @Table macro
Entry.Draft(
  id: Tagged<Entry, UUID>? = nil, // ✅ optional — omitted from INSERT, SQL DEFAULT fires
  createdAt: Date = now(), // ❌ always included in INSERT, SQL DEFAULT never fires
  updatedAt: Date = now(), // ❌ always included in INSERT, SQL DEFAULT never fires
  notes: String = ""
)

When creating Entry.Draft(notes: "Hello"), the SQL becomes something like this:

INSERT INTO "entries" ("id", "createdAt", "updatedAt", "notes")
VALUES (NULL, '2026-04-05 00:00:00.000', '2026-04-05 00:00:00.000', 'Hello')

The createdAt and updatedAt columns get the draft creation time instead of SQL DEFAULT (now()) (insertion time).

Workarounds considered

1. Make fields optional in the Table itself (var createdAt: Date?). This works — nil in Draft causes the column to be omitted from INSERT, so the SQL DEFAULT fires. But it forces optionals throughout the app, even though the value is never actually nil after a save.

2. Use sentinel value and AFTER INSERT triggers to overwrite the sentinel. For example, one could use Date.distantPast or Date.distantFuture as a representation for unsaved entries. But this approach goes against Swift best practices.

Desired behavior

A way to keep the field non-optional on the Table type while making it optional on Draft, so that the SQL DEFAULT fires when omitted:

// Hypothetical
Entry.Draft(notes: "Hello")
// createdAt: nil → omitted from INSERT → SQL DEFAULT (now()) fires
// updatedAt: nil → omitted from INSERT → SQL DEFAULT (now()) fires

// Seed data with explicit dates still works
Entry.Draft(createdAt: someDate, notes: "Seed")
// createdAt: someDate → included in INSERT → explicit value used

This pattern is common for any field where the database owns the default value (timestamps, sequences, computed defaults) but the app always expects a non-nil value after reading.

---

I searched the existing issues and discussions in this repo and didn't find a prior request or solution for this. Happy to help with a PR if there's a direction you'd prefer.

[mbrandonw]

Hi @igorcamilo, this was discussed in #30 and an attempt was made to implement it (#36), but there are still a lot of open questions. We would need to think through all of those subtleties before making changes.

[igorcamilo]

Hi @mbrandonw thanks for the reply. Great to know that you guys are aware of this use case. So for now I’ll keep using my workaround.