mbw234

It persists data to disk in a manner that is easy to query. It allows observing changes to the data so that features update when necessary. It handles graphs of objects just fine thanks to recursive CTE's in SQLite. With a little bit of work it can handle historical edits with undo/redo. It seems to quack like Swift/Core Data to me, but bringing SQLite to the forefront instead of putting needless abstraction layers on top of it.

mbw234

10 mesi fadiscuss

> I want to be able to write raw SQL and have the compiler check that SQL for correctness and generate the proper bindings and types for using it.

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
    )

mbw234

10 mesi fadiscuss

Sorry about that, just opened a PR to update the readme and docs landing page! Previously it was very clear that GRDB was being used under the hood, but now we will say it explicitly.

mbw234

10 mesi fadiscuss

I'm half of Point-Free and can answer your questions.

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.

mbw234

4 anni fadiscuss

Sorry about that, broken links have been fixed in the episode and here's a link to the library: https://github.com/pointfreeco/swift-parsing.

Submissions

Cross-Platform Swift: Building a Swift App for the Browser

Tour of Parser-Printers: Introduction

Isowords: Open-source game built in SwiftUI and the Composable Architecture

The Composable Architecture

Seemingly Impossible Swift Programs

DSLs vs. Templating Languages

Exploring contravariance using Swift

Tagged: a library for making Swift code more type-safe

Server-Side Swift from Scratch

Point-Free: A video series on functional programming and Swift

Composable HTML views in Swift

Anything you can do, I can do better. Swift and Kotlin

comments