Use kysely instead of mikro-orm#250
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Deploying happychain with
|
| Latest commit: |
ce7a4af
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://e101251f.happychain.pages.dev |
| Branch Preview URL: | https://gabriel-chore-change-orm.happychain.pages.dev |
not-reed
left a comment
There was a problem hiding this comment.
kysely to take over the world 😈 😁 jk, but i do like it
36d0751 to
8fdcc44
Compare
8fdcc44 to
7df84a7
Compare
norswap
left a comment
There was a problem hiding this comment.
Good stuff! My main comment is we should probably reintroduce something like flush so we avoid writing txs multiple times to the DB with no changes.
|
|
||
| const result = await ResultAsync.fromPromise( | ||
| this.transactionManager.transactionRepository.flush(), | ||
| this.transactionManager.transactionRepository.updateTransactions(transactions), |
There was a problem hiding this comment.
Maybe we should reintroduce a flush abstraction (probably implemented via a "dirty" flag in Transaction). Some of these transactions will have been written to db already due to their handling, so rewriting them is inefficient.
Maybe some also don't change at all after going through the monitor?
There was a problem hiding this comment.
I have created a new issue to address this because it is better to implement it on top of all the changes we currently have. In the PR for prune TX, I added the updatedAt field, which we can use to determine whether we need to flush or not.
https://linear.app/happychain/issue/HAPPY-250/only-flush-transactions-that-have-been-modified
| } else if (it.status === "Error") { | ||
| console.error(`failed to execute migration "${it.migrationName}"`) | ||
| } | ||
| }) |
There was a problem hiding this comment.
Just out of curiosity, how does it track which migrations have already been applied, do kysely maintain its own db of applied migrations?
| this.txmgr.transactionRepository.saveTransactions(transactionsBatch) | ||
| const saveResult = await this.txmgr.transactionRepository.saveTransactions(transactionsBatch) | ||
|
|
||
| // TODO: If flush fails, we should notify the user |
There was a problem hiding this comment.
We should preserve that TODO (do we have a related issue?), as similarly, we can still fail to write the tx to DB.
There was a problem hiding this comment.
I added the comment again and I created an issue to implement the notification. Now it's possible given that we have the hook system
There was a problem hiding this comment.
| const result = await ResultAsync.fromPromise( | ||
| db.transaction().execute(async (dbTransaction) => { | ||
| const promises = transactions.map((t) => | ||
| dbTransaction.insertInto("transaction").values(t.toDbRow()).execute(), |
There was a problem hiding this comment.
I think we could do a single insert statement that inserts all transactions at once instead of a transaction that contains a bunch of singular insert statements.
There was a problem hiding this comment.
You are right
There was a problem hiding this comment.
I think it's still doing multiple SQL queries under the hood. I think it should look something like this: https://kysely.dev/docs/examples/insert/multiple-rows
Either fix it here, or open a new issue (post here) for this and merge this one.
There was a problem hiding this comment.
I am going to merge because there is no update function to update multiple rows
7df84a7 to
2ac9c34
Compare


Linked Issues
Description
We are experiencing issues with bundling and Mikro-ORM. The problem is that Mikro-ORM cannot detect decorators in the bundled file due to how Bun transpiles the code from TypeScript to JavaScript.
After consideration, we have decided to use Kysely instead of Mikro-ORM. Kysely is not an ORM, it's a type-safe query builder.
An important change introduced by this PR is that we no longer have an entity manager, as we did with Mikro-ORM. For this reason, we now need to explicitly update every transaction we modify by calling the repository, instead of simply making changes and then flushing, as was the case with Mikro-ORM. I think this is actually an improvement, as it makes the code cleaner. Now, we have full control over what and when we commit a change to the database.
More context:
Toggle Checklist
Checklist
Basics
norswap/build-system-caching).Reminder: PR review guidelines
Correctness
testnet, mainnet, standalone wallet, ...).
I tested it using the randomness service connected to Anvil
and have updated the code & comments accordingly.
Architecture & Documentation
(2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
comments.
in a Markdown document.