Feature Request: Option to skip invalid records in @FetchAll instead of failing entire fetch

[mpgrill]

Hey @mbrandonw @stephencelis,

Thanks for the great work on SQLiteData!

Problem

When using @FetchAll with types conforming to QueryBindable, a single record with an invalid enum value causes the entire fetch to fail, returning zero results instead of partial results with invalid records skipped.

Real-world scenario:

• Working on a feature branch with new enum cases
• Main branch doesn't have those cases yet
• Database contains records from feature branch
• @FetchAll in main branch returns 0 records (instead of skipping unknown records)

This is particularly problematic for:

• Feature flags from services like PostHog/LaunchDarkly
• Multi-branch development with shared databases
• App rollback scenarios (newer data, older app)
• Gradual enum rollout across app versions

Current Behavior

enum FeatureFlagKey: String, QueryBindable {
    case featureA
    case featureB
    // featureC exists in another branch but not here
}

@Table("featureFlag")
struct FeatureFlag: Codable {
    let key: FeatureFlagKey
    let isOn: Bool
}

@FetchAll(FeatureFlag.all) var flags: [FeatureFlag]
// Returns: [] (empty) because ONE record has key = "featureC"
// Expected: [FeatureFlag(key: .featureA), FeatureFlag(key: .featureB)]

When the fetch encounters a record with key = "featureC", the init(decoder:) in QueryBindable throws, and the entire fetch fails.

Root Cause: QueryBindable Decoder

The issue occurs in the init(decoder:) required by QueryDecodable:

extension FeatureFlagKey: QueryBindable {
    init(decoder: inout some StructuredQueriesCore.QueryDecoder) throws {
        guard let string = try decoder.decode(String.self),
              let key = FeatureFlagKey(rawValue: string)
        else {
            // Throwing here breaks the ENTIRE fetch
            throw QueryDecodingError.missingRequiredColumn
        }
        self = key
    }
}

When this throws:

1. The decoder state gets corrupted
2. Subsequent columns can't be read (we saw "lastUpdated column is NULL" errors even when it wasn't)
3. The entire @FetchAll returns empty array

Current Workaround

We implemented a fallback pattern with an .unknown sentinel case:

QueryBindable Implementation

enum FeatureFlagKey: String, CaseIterable, Codable {
    case featureA
    case featureB
    case unknown= "__unknown__"  // Sentinel for invalid values
}

extension FeatureFlagKey: QueryBindable {
    var queryBinding: QueryBinding {
        .text(rawValue)
    }

    init?(queryBinding: QueryBinding) {
        guard case .text(let string) = queryBinding else {
            return nil
        }

        if let key = FeatureFlagKey(rawValue: string) {
            self = key
        } else {
            print("⚠️ Unknown feature flag key: \(string)")
            self = .unknown  // Fallback instead of failing
        }
    }

    init(decoder: inout some StructuredQueriesCore.QueryDecoder) throws {
        guard let string = try decoder.decode(String.self) else {
            self = .unknown
            return
        }

        if let key = FeatureFlagKey(rawValue: string) {
            self = key
        } else {
            print("⚠️ Unknown feature flag key: \(string)")
            self = .unknown  // Fallback instead of throwing
        }
    }
}

Codable Implementation (Secondary)

extension FeatureFlagKey {
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let rawValue = try container.decode(String.self)

        if let value = FeatureFlagKey(rawValue: rawValue) {
            self = value
        } else {
            print("⚠️ Unknown feature flag key: \(rawValue)")
            self = .unknown
        }
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        try container.encode(rawValue)
    }
}

This works but requires:

• Every enum to add an .unknown case
• Custom QueryBindable and Codable implementations for every enum
• Boilerplate code that should be handled at the framework level

Proposed Solutions

Option 1: Fetch-level Configuration

@FetchAll(FeatureFlag.all, skipInvalid: true) var flags: [FeatureFlag]

Option 2: Query Modifier

static var all: Select<Self, Self, ()> {
    FeatureFlag
        .selectStar()
        .skipInvalidRecords()  // Continues on decode failures
}

Option 3: Global Database Configuration

// In database setup
database.configuration.skipInvalidRecords = true

Questions

1. Is the current fail-fast behavior intentional? (e.g., to catch data corruption early)
2. Would an opt-in "skip invalid records" feature be acceptable?
3. Should skipped records be logged/reported somewhere? (e.g., via callback or diagnostics)
4. Are there performance concerns with try-catch on every record?
5. What's the recommended pattern for enum evolution in production apps?

Use Cases

This feature would be valuable for:

• Feature flags - Remote services (PostHog, LaunchDarkly) may add/remove flags
• A/B testing - Conditional features that exist in some branches but not others
• App rollback - Older app version reading newer database with unknown enum values
• Multi-branch development - Shared databases between feature branches
• Backward compatibility - Graceful degradation when enum cases are removed
• Server-driven enums - API sends enum values the app doesn't know about yet

Would love to hear thoughts on the best approach for this!

[mbrandonw]

Hi @mpgrill, I don't think this is likely a feature we will support. We feel it is better to have a single, consistent behavior for decoding records for SQLite, and if you deviate from that behavior, then it's on you to provide a localized solution like you did with your custom QueryBindable conformance. Codable in Swift works the same way.

However, I think an even better solution here is to not use an enum at all for your domain. If you really do have an open ended enum that can have different cases on different devices, then an enum is probably not the best tool. Are you ever actually switching on the enum in your code? If not, then it could just be a RawRepresentable struct:

struct FeatureKey: RawRepresentable, QueryBindable {
  var rawValue: String
  static let featureA = Self(rawValue: "featureA")
  static let featureB = Self(rawValue: "featureB")
}

This allows you to still reference features with a static dot-syntax such as .featureA, but it also naturally handles the "unknown" case just fine since it's just a raw representable string.

And if you are switching on your FeatureKey enum somewhere in your code base, are you sure it's actually necessary to? Can those switches be implemented in a way that does not require needing to exhaustively know about every case available?

[mpgrill]

Hi @mbrandonw,

Thank you for the thorough response.

Your proposal makes a lot of sense and would probably be a better fit here. I'm only switching on feature flags within computed properties inside the enum for more developer facing things like a human readable title. I do however leverage CaseIterable to seed the database with the state of feature flags pulled from remote.

I didn't do a very good job considering the fluid nature of feature flags when designing this and its impact on the database. Wasn't a problem in my case (and there are solid workarounds already built in), but I imagine it could be a painful lesson for others to learn that one corrupted record breaks their entire fetch.

That said, I can't imagine this will be a common situation others run into in the wild. I just wanted to share my experience here in case it was something you all hadn't considered.

Thanks for the great work on this library. I'm a big fan of Point-Free and have crucially leveraged snapshot tests and dependencies as part of my project as well.

[mbrandonw]

I'm only switching on feature flags within computed properties inside the enum for more developer facing things like a human readable title.

This can also be easily done using raw representable structs:

struct FeatureKey: RawRepresentable, QueryBindable {
  var rawValue: String
  let title: String
  static let featureA = Self(rawValue: "featureA", title: "Feature A")
  static let featureB = Self(rawValue: "featureB", title: "Feature B")
}

If you find yourself repeatedly switching on an enum just to compute a value for each case, then most likely you don't need it to be an enum and that value can just be a property on a struct.

I do however leverage CaseIterable to seed the database with the state of feature flags pulled from remote.

This can either be managed manually:

struct FeatureKey: RawRepresentable, QueryBindable {
  var rawValue: String
  let title: String
  static let allFlags: [Self] = [.featureA, .featureB]
}

Or you can even write a macro to do this for you.

I didn't do a very good job considering the fluid nature of feature flags when designing this and its impact on the database.

Luckily even though you may have started with an enum now, it is quite easy to migrate it to a struct so that you will have a better model for your domain in the future. Should be possible to do it in a non-breaking fashion too.