Multiple database support

[yliu342]

Hi thanks again for putting this nice tool allowing integrating GRDB and the Share state possible. We currently have an application that uses TCA + Share State. We are considering moving to using SharingGRDB to back our data but currently seeing some limitation to be able to switch DB.

Our app currently can connect to different DBs depending on which user is logged in, when trying to use sharing-grdb we've seen it only allow to call the prepareDependencies once in an app lifetime and stuck with the database that was returned in the prepareDependencies. Since then we've been trying on finding if there is a way to support our need to be able to switch db.

What we've done so far is created a new dependency to manage the DB switching and extend the SharedReaderKey adding a custom fetch key which we can call the .fetch() key with a custom DB.

public extension SharedReaderKey {
    private static func fetchDatabase() -> any DatabaseWriter {
        @Dependency(\.appDatabaseClient) var appDatabase
        return appDatabase.getDatabase()
    }

    static func lsfetch<Value>(
        _ request: some FetchKeyRequest<Value>,
        scheduler: some ValueObservationScheduler = .async(onQueue: .main)
    ) -> Self
        where Self == FetchKey<Value>
    {
        return .fetch(request, database: fetchDatabase(), scheduler: scheduler)
    }
}

With the above code it sort of works, we were able to use the dynamic query format like @SharedReader(value: []) var remindersList: [RemindersLists.Record] within the reducer and it can fetch from the appropriate DB. However when we try using the static format @SharedReader(.lsfetch(RemindersLists())) var staticListQuery: [RemindersLists.Record] this query will only query from the first database that setup the query. Looking at the code it was due to the FetchKeyID got stored in an internal storage.

We are just wondering what we are doing is something that is reasonable and we should continue to explore or if the lib is not intended for such a case and we should stop and better with a pure GRDB approach?

Thank you

[stephencelis]

@yliu342 This is a bug that wasn't present in the episode code but we must've forgotten to address it in the release.

Will be fixed when this is merged and released! #26

[yliu342]

Thank you for the fast follow up. Just want to get an idea from you guys if what we are doing is sensible or not if there are any other gotchas that we need to be careful? Will there be a library native support for such a case i.e. switching/changing db in the future?

[stephencelis]

That should be totally sensible. Want to bump to 0.1.1 and see if things are fixed for you?

[yliu342]

Yep, updated to 0.1.1 and it works as expected. Thank you.