Saving Data property in SQLiteData model

[mario-luis-dev]

I have a question about SQLiteData pertaining to the storage of Data properties in a model: is there an alternative (either existing or planned) to SwiftData’s @Attribute(.externalStorage)?

[mbrandonw]

Hi @mario-luis-dev, this is not currently possible and it is not planned. It is worth noting the very sharp edges of @Attribute(.externalStorage) and why we are hesitant to recreate it exactly as it exists in SwiftData.

Consider a model with data that does not store it externally:

@Model
final class Item {
  var asset: Data
  // …
}

With this kind of model it is totally fine to search for an item that matches some specific bytes:

let bytes = Data(…)

#Predicate { item in
  item.asset == bytes
}

This kind of query compiles, and can be executed just fine at runtime.

However, if we change the model like so:

@Model
final class Item {
  @Attribute(.externalStorage)
  var asset: Data
  // …
}

The predicate above will still compile, but it's actually undetermined whether executing the predicate will succeed or crash at runtime. If there are any rows whose data has been moved to external storage, then referencing that data in a query can only crash because SwiftData is not going to load that data into memory just to query against it. But, if no rows have data stored externally, then this kind of query can work just fine.

To us that is a huge problem, and it's not clear how to solve such a problem.

But, to back up a bit, we would like to know a bit more about why you need such a tool. Our recommendation, which aligns with SQLite's recommendation too, is to just store the data blobs directly in SQLite. If the blobs aren't too big, then SQLite can handle this just fine. It is also further recommneded to put data blobs in their own table with a 1-1 relationship to the table that wants the asset. This helps make sure that queries on your table are not slowed down by the data blobs, and that you don't accidentally load data into memory when you don't need it.

This isn't always going to be appropriate, but it can be surprising how well it works for many types of apps.