-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New SQLite driver: capacitor-sqlite #484
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for your contribution!
I reviewed your PR and mostly have minor comments to improve readability. However, i do have one major concern. The transaction<T>
method of the adapter is managing the transaction manually by calling BEGIN
and COMMIT
/ABORT
.
This is prone to concurrency issues if one would call transaction<T>
before the previous transaction finished; in which case the transactions will get interleaved. Even if we assume that clients won't do that, a similar issue could still occur when clients call transaction<T>
(e.g. as a result of calling db.items.create
) and concurrently there is a transaction coming in via the replication stream and being applied.
We've had similar issues with the wa-sqlite
driver and solved them by using a mutex as to ensure that the adapter never tries to run two transactions concurrently. I suggest you have a look at the implementation of transaction<T>
in the wa-sqlite driver.
const wrapInTransaction = true; | ||
|
||
return this.db.executeSet(set, wrapInTransaction).then( (result: capSQLiteChanges) => { | ||
// TODO: unsure how capacitor-sqlite populates the changes value (additive?), and what is expected of electric here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We expect the changes to be additive, i.e. the total amount of changes accumulated over all the statements in this transaction. For example, in the better-sqlite3
adapter we have to accumulate those changes manually. Could you write a test for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd need to write a test against a real db, not the mock. What I can do for now is ask @samwillis to double check this in his example project.
All requested changes implemented, all tests still pass. Thank you for the review! The only change that is more than a stylistic or readability refactor is the mutex implementation. I've left that conversation unresolved. |
Hey @gregzo, good news, with the two small changes I've comment on this worked with my demo app (I've tested iOS but not android yet, but I don't think that will change anything) 😁 It looks like you also have an issue with |
@samwillis pnpm-lock now up to date. FYI ran into this known pnpm issue: pnpm/pnpm#1801 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job @gregzo!
Driver looks great, i'm waiting for the tests to finish and will merge afterwards.
Thanks again for your amazing contribution 💯
@gregzo Could you run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you merged main
into your PR branch. We don't do that normally and instead rebase PR branches on top of main.
Please rebase your branch on top of the latest main
and remove the merge commit and the Version Packages one. Let me know if you need a hand with that.
The E2E test failures seem to be caused by the fact that your branch is based on an older version of the server. When you rebase it on top of the latest main, the E2E problems should be resolved. |
4637899
to
8a301ac
Compare
…tches native calls.
@gregzo Rebase looks great. Thanks! I was just about to comment about the pnpm lockfile update. I've pushed a commit for it here. But you beat me to it. Did you also get these warnings when you ran
I'm wondering if there are any fixes we need to apply to our deps. And it's curious that the lockfile version dropped to |
Rebased on electric/main and added changeset. E2E tests still fail though - happy to follow your lead if there's anything else I can do. Edit: all tests pass. Got 3 failure notifications in my inbox after pushing, among them E2E. All seems well now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🏅
@alco Yes, I encountered the same warnings. |
This PR adds compatibility with capacitor-community/sqlite via a new adapter and accompanying plumbing and tests.
We could envisage asking
capacitor-community/sqlite
's maintainer to have a quick look to ensure that there's no flagrant misuse of its APIs. As it stands, all tests pass but using a mock database.This adapter implementation is built on my understanding of
electric
andcapacitor-community/sqlite
documentation and codebase. Much more extensive real-world testing is imo required.