mbw234
Joined 10 years ago
Joined 10 years ago
Our library does allow this a little bit, in addition to a Swift API for building queries. You can write SQL as a string while still using the schema information exposed from the @Table macro. For example, a query to select all reminders lists along with a count of the reminders in each list:
@Table struct RemindersList {
let id: UUID
var title = ""
}
@Table struct Reminder {
let id: UUID
var title = ""
var remindersListID: RemindersList.ID
}
#sql("""
SELECT \(RemindersList.title), \(Reminder.id.count())
FROM \(RemindersList.self)
LEFT JOIN \(Reminder.self) ON \(RemindersList.id) = \(Reminder.remindersListID)
GROUP BY \(RemindersList.id)
""",
as: (String, Int).self
)The fact that our library deploys back to iOS 13 is just our way of showing we care deeply about back deploying these tools so that anyone can use them. Certainly no one is deploying iOS 13 apps these days, but people definitely are deploying iOS 16 apps (and may be for another year or two), which has no access to SwiftData.
And investing time into learning a third party library is just the name of the game when one feels that the tools Apple provides do not suit their needs. Luckily our library mimics many of the patterns that one is used to with SwiftUI and SwiftData, but has the benefits of being based on SQLite, is open source, and not a proprietary technology.
And I'm not sure what wheel we are reinventing here. We feel most of our libraries are specifically filling holes that Apple has left open. We also don't do a ton of paid support with companies, but we certainly do answer dozens of questions on Slack, Twitter, GitHub discussion, etc, every day. All for free.