Guidance on how to use SQLite data in a manager class

[BennoCrafter]

Hey, so I’m currently trying to figure out how to integrate this library into a Manager class. When I tried the most obvious approach, initialising it in the main app’s initialisation and having an observable singleton class, I got an error saying I can’t initialise it a second time. Any guidance would be great, or is the Manager class the wrong approach here?

[mbrandonw]

Hi @BennoCrafter, I'm not sure what you mean by "manager class", so any sample code you can share will be helpful.

[BennoCrafter]

hi! for sure.

So this is my main entry

@main
struct TimetableApp: App {
    // @UIApplicationDelegateAdaptor private var appDelegate: AppDelegate

    @Environment(\.scenePhase) private var scenePhase
    @AppStorage(AppStorageKeys.hasSeenOnboarding.keyName()) private var hasSeenOnboarding: Bool = false
    @StateObject var alertManager: AlertManager = .init()
    @Dependency(\.context) var context
    @ObservedObject var timetableManager = TimetableManager.shared
    @Dependency(\.defaultDatabase) private var database

    init() {
        if context == .live {
            try! prepareDependencies {
                try $0.bootstrapDatabase()
            }
        }
        timetableManager.load()
    }

And a simplified version of TimetableManager (which is the manager class im talking about):

class TimetableManager: ObservableObject {
    static let shared = TimetableManager()

    @ObservationIgnored
    @FetchAll var events: [Event]

    @Published var appConfig = AppConfig()

    @ObservationIgnored @Dependency(\.defaultDatabase) private var database

    private let logger = Logger(subsystem: "TimetableManager", category: "Database")

    private init() {}

    func load() {}

    func appDatabase() throws -> any DatabaseWriter {
        var configuration = Configuration()

        let database = try defaultDatabase(configuration: configuration)
        logger.info("Open Database: '\(database.path)'")

        var migrator = DatabaseMigrator()
        #if DEBUG
        migrator.eraseDatabaseOnSchemaChange = true
        #endif
        migrator.registerMigration("Create initial tables") { db in
            let defaultEventColor = Color.HexRepresentation(queryOutput: Event.defaultColor).hexValue
            let defaultTemplateColor = Color.HexRepresentation(queryOutput: EventTemplate.defaultColor).hexValue

            // MARK: - Events

            try #sql(
                """
                CREATE TABLE "events" (
                  "id" TEXT PRIMARY KEY NOT NULL ON CONFLICT REPLACE DEFAULT (uuid()),
                  "name" TEXT NOT NULL ON CONFLICT REPLACE DEFAULT 'UNKNOWN',
                  "color" INTEGER NOT NULL ON CONFLICT REPLACE DEFAULT \(raw: defaultEventColor ?? 0),
                  "startDate" TEXT NOT NULL ON CONFLICT REPLACE DEFAULT (date('1970-01-01')),
                  "endDate" TEXT NOT NULL ON CONFLICT REPLACE DEFAULT (date('9999-12-31')),
                  "useDateOnly" INTEGER NOT NULL ON CONFLICT REPLACE DEFAULT 0,
                  "note" TEXT,
                  "occurrenceId" TEXT REFERENCES "occurrences"("id") ON DELETE SET NULL,
                  "templateId" TEXT REFERENCES "eventTemplates"("id") ON DELETE SET NULL,
                  "isLocked" INTEGER NOT NULL ON CONFLICT REPLACE DEFAULT 0
                ) STRICT
                """
            ).execute(db)
        }

        try migrator.migrate(database)
        return database
    }
  
  func addEvent(_ event: Event) {
    // insert into table
  }

Simply said what. I mean by a manager class. It's an Environment object which I access in my different views and can perform different IO tasks to it. E.g. simplified adding an item to a table.

[mbrandonw]

Is there any bigger app built with SQLite data than the current examples? Would be very interesting.

I feel that the demo apps do properly show how to structure an app to use SQLiteData. I don't think a "bigger" app will show anything new.

[BennoCrafter]

Ok I see now. The problem is this line in your app entry point:

@ObservedObject var timetableManager = TimetableManager.shared

That eagerly creates the timetableManager, which in turn accesses the database via @FetchAll. And you can't override a dependency with prepareDependencies if it has already been accessed.

This is why we use static lets in the entry point of our demo apps:

sqlite-data/Examples/Reminders/RemindersApp.swift

Line 13 in 833b762

static let model = RemindersListsModel()

That means the model will not actually be created until it is accessed in the view, and by then prepareDependencies as run.

Overall I would suggest cleaning up a number of things in this code snippet:

• Try to delay the creating of any observable models until after the initializer of the entry point has run.

• Can you use @Observable instead of ObservableObject? That makes it easier to embrace this pattern of delaying initialization.

• And unrelated to the above, but are you sure startDate and endDate should have default values of far past and far future? Wouldn't it be better for them to be optional?

Thank you very much for your so fast and detailed answer. To your points mentioned. Yeah I've already thought of making it optional, but just copied it from my old SwiftData model. I'll try removing ObservableObject and replace it with Observable. And thanks again for this clear answer. Really appreciate it 🙏

[BennoCrafter]

In your samples, you don’t use environment objects. Do you think your approach, like in the reminders example, is the right one? So hand over the data model object to the views.

[mbrandonw]

Well, I'm not entirely sure what your ObservableObject is really bringing to the table. First of all, it's a singleton, so you don't even need to put it in the environment. It's already globally available. But typically I would highly recommend against using a singleton.

And further, the database is also already a global and available from anywhere at anytime. You can use the @FetchAll tools whenever you want. So I don't see what the environment object is bring to that either.

So yes, we generally would not use an environment object in our apps, and as you can see from the demos it's really never needed. Each individual feature takes care of querying the database however it wants.

[BennoCrafter]

In your own projects you just hand over the data model as a parameter to the view. So that would be an alternative ig