You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would you mind elaborating on why GRDB with a custom SQLite build has a different module name from the ordinary GRDB? I ask because there is a major practical problem with the current convention. As-is, no framework that imports "GRDB" (e.g. GRDBCombine) is source compatible with GRDBCustomSQLite. Yet I don't understand why the underlying implementation of SQLite should be reflected in the module name, as long as the underlying code is API-compatible.
Even in my app's source code, I don't see a reason it needs to know whether I'm linking against the implementation of GRDB with the standard SQLite build or an implementation with a custom SQLite build—except for where I'm using the custom interface. But shouldn't those differences be restricted to the smallest possible API surface area?
The text was updated successfully, but these errors were encountered:
Would you mind elaborating on why GRDB with a custom SQLite build has a different module name from the ordinary GRDB? I ask because there is a major practical problem with the current convention. As-is, no framework that imports "GRDB" (e.g. GRDBCombine) is source compatible with GRDBCustomSQLite. Yet I don't understand why the underlying implementation of SQLite should be reflected in the module name, as long as the underlying code is API-compatible.
Even in my app's source code, I don't see a reason it needs to know whether I'm linking against the implementation of GRDB with the standard SQLite build or an implementation with a custom SQLite build—except for where I'm using the custom interface. But shouldn't those differences be restricted to the smallest possible API surface area?
The text was updated successfully, but these errors were encountered: