Compile :common project for the web#354
Draft
simolus3 wants to merge 3 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is blocked on
androidx.sqliteversion2.7.0, which is currently in alpha.This adds support for compiling (most) of the
:commonproject for the web. This doesn't actually add web support, but it gets:commoninto a state where providing a web implementation of ourSQLiteConnectionPoolinterface would make it run on the web. A future PR would provide that as a builtin option.The key challenge here is that we assume synchronous SQLite calls in many places of the SDK. On the web however, preparing or stepping through statements is fundamentally asynchronous. To reconcile this without a breaking change, we adopt this pattern:
suspendfunction, which is fine because we run the entire callback in aDispatchers.IOcontext.In Kotlin, we can express this with
expect interfaces:expect interfaces with only the non-blocking APIs.actual interfacealso adding the blocking APIs. This allows us to preserve both source and binary compatibility, since blocking methods still exist in the exact same location.To be able to use suspending functions, this adds asynchronous methods to
ConnectionContextandQueries. This also refactors the implementation ofQueriesto use default methods based onuseConnection.On the web, we initially won't support:
fetch()streams).PowerSyncDatabase()factory method (onlyPowerSyncDatabase.openedis supported).There's obviously a lot more to do, but this should be a decent initial step.