[WIP] GRDB Migration #683
[WIP] GRDB Migration #683
Conversation
| try db.create(table: GRDBPageBookmark.databaseTableName, options: .ifNotExists) { table in | ||
| // Don't think we need a separate local id column. | ||
| table.column("page", .integer).primaryKey() | ||
| table.column("remote_id", .text) |
There was a problem hiding this comment.
I think This should be non-null, since PageBookmarks table would be the persistence for synchronized information and doesn't hold local mutations.
| import VLogging | ||
| import SQLitePersistence | ||
|
|
||
| public struct GRDBPageBookmarkPersistence: PageBookmarkPersistence { |
There was a problem hiding this comment.
I don't think it needs to conform to PageBookmarkPersistence. PageBookmarkPersistence is basically the repository (the pattern) API. Now GRDBPageBookmarkPersistence is not going to be used directly, instead it will be just a data source. This allows us to be able to supply a tailored entity that includes the remote ID as part of it.
There was a problem hiding this comment.
I was actually operating on the design that it's going to replace bookmarks' CoreDataPersistence in the app.
- At the launch of the next update, data is migrated from CoreData to this one.
GRDBPageBookmarkPersistenceis going to be the source of truth as far the app's presentation is concerned.- Some other storage will be created to handle sync-related concerns. i.e. local changes, last synced date, ... This is most likely going to be transient; once synced, local changes are going to be wiped and last synced date updated.
There was a problem hiding this comment.
I see two things we need that would make GRDBPageBookmarkPersistence not applicable to be the public API:
GRDBPageBookmarkPersistenceonly holds synchronized data. We need an additional persistence layer to store offline mutations that haven't been synchronized with the server yet (e.g.,GRDBPageBookmarkMutationsPersistence).- We need a higher-level class to manage interactions between different data sources (
GRDBPageBookmarkPersistence,GRDBPageBookmarkMutationsPersistence, andQuran.com RemoteDataSource). This is typically implemented using the repository pattern. See an example here:https://developer.android.com/topic/architecture/data-layer.
There was a problem hiding this comment.
I get your point, and it makes sense.
| /// Creates a publisher that tracks changes in the results of database requests, | ||
| /// and notifies fresh values whenever the database changes | ||
| /// | ||
| /// The first value is notified when the publisher is created. Subsequent changes *may* get coalesced in notifications. | ||
| public func readPublisher<T>(_ block: @Sendable @escaping (Database) throws -> T) throws -> AnyPublisher<T, Error> { | ||
| // - ValueObservation may coalesce subsequent changes into a single notification | ||
| // - ValueObservation fetches a fresh value immediately after a change *is committed in the database*. | ||
| // - By default, delivers on the main thread. | ||
| ValueObservation |
There was a problem hiding this comment.
@mohamede1945 See here and see the test below.
I've pulled the inner comments from the documentation of ValueObservation.
First draft: shows a working example for a GRDB stack for page bookmarks. Tests will be similar to the CoreData variant, except that the GRDB's integration with Combine doesn't guarantee that publishers will signal every time the resources is mutated, instead it might aggregate a few mutations together.
Also, still remains to test the publisher function in
DatabaseConnection.