Skip to content

Use kysely instead of mikro-orm#250

Merged
GabrielMartinezRodriguez merged 10 commits into
masterfrom
gabriel/chore-change-orm
Dec 6, 2024
Merged

Use kysely instead of mikro-orm#250
GabrielMartinezRodriguez merged 10 commits into
masterfrom
gabriel/chore-change-orm

Conversation

@GabrielMartinezRodriguez

@GabrielMartinezRodriguez GabrielMartinezRodriguez commented Nov 11, 2024

Copy link
Copy Markdown
Contributor

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

  • B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
  • B2. This PR is not so big that it should be split & addresses only one concern.
  • B3. The PR targets the lowest branch it can (ideally master).

Reminder: PR review guidelines

Correctness

  • C1. Builds and passes tests.
  • C2. The code is properly parameterized & compatible with different environments (e.g. local,
    testnet, mainnet, standalone wallet, ...).
  • C3. I have manually tested my changes & connected features.

I tested it using the randomness service connected to Anvil

  • C4. I have performed a thorough self-review of my code after submitting the PR,
    and have updated the code & comments accordingly.

Architecture & Documentation

  • D1. I made it easy to reason locally about the code, by (1) using proper abstraction boundaries,
    (2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
  • D2. All public-facing APIs & meaningful (non-local) internal APIs are properly documented in code
    comments.
  • D3. If appropriate, the general architecture of the code is documented in a code comment or
    in a Markdown document.

GabrielMartinezRodriguez commented Nov 11, 2024

Copy link
Copy Markdown
Contributor Author

@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Nov 11, 2024

Copy link
Copy Markdown

Deploying happychain with  Cloudflare Pages  Cloudflare Pages

Latest commit: ce7a4af
Status: ✅  Deploy successful!
Preview URL: https://e101251f.happychain.pages.dev
Branch Preview URL: https://gabriel-chore-change-orm.happychain.pages.dev

View logs

@GabrielMartinezRodriguez GabrielMartinezRodriguez added the reviewing-1 Ready for, or undergoing first-line review label Nov 11, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez marked this pull request as ready for review November 11, 2024 21:10
Comment thread packages/randomness-service/build.config.ts

@not-reed not-reed left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kysely to take over the world 😈 😁 jk, but i do like it

Comment thread packages/transaction-manager/lib/migrate.ts Outdated
Comment thread packages/randomness-service/build.config.ts
@GabrielMartinezRodriguez GabrielMartinezRodriguez changed the title feat(txm): use kisely instead of mikro-orm Use kisely instead of mikro-orm Nov 11, 2024
This was referenced Nov 11, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez changed the title Use kisely instead of mikro-orm Use kysely instead of mikro-orm Nov 11, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez removed the reviewing-1 Ready for, or undergoing first-line review label Nov 13, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez added the reviewing-2 Ready for, or undergoing final review label Nov 14, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez mentioned this pull request Nov 20, 2024
10 tasks
@GabrielMartinezRodriguez GabrielMartinezRodriguez mentioned this pull request Nov 28, 2024
10 tasks

@norswap norswap left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread packages/iframe/src/routeTree.gen.ts
Comment thread packages/transaction-manager/lib/Transaction.ts
Comment thread packages/transaction-manager/package.json

const result = await ResultAsync.fromPromise(
this.transactionManager.transactionRepository.flush(),
this.transactionManager.transactionRepository.updateTransactions(transactions),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}"`)
}
})

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just out of curiosity, how does it track which migrations have already been applied, do kysely maintain its own db of applied migrations?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, Kisely creates two tables in our database to track which migrations have been executed:

image

this.txmgr.transactionRepository.saveTransactions(transactionsBatch)
const saveResult = await this.txmgr.transactionRepository.saveTransactions(transactionsBatch)

// TODO: If flush fails, we should notify the user

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should preserve that TODO (do we have a related issue?), as similarly, we can still fail to write the tx to DB.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const result = await ResultAsync.fromPromise(
db.transaction().execute(async (dbTransaction) => {
const promises = transactions.map((t) =>
dbTransaction.insertInto("transaction").values(t.toDbRow()).execute(),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am going to merge because there is no update function to update multiple rows

https://kysely.dev/docs/examples/update/single-row

@norswap norswap added updating Updating after review and removed reviewing-2 Ready for, or undergoing final review labels Dec 4, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez added reviewing-2 Ready for, or undergoing final review and removed updating Updating after review labels Dec 5, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez mentioned this pull request Dec 5, 2024
10 tasks
@norswap norswap added merge-after-changes Can be merged after requested changes are made and removed reviewing-2 Ready for, or undergoing final review labels Dec 5, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez merged commit c8018df into master Dec 6, 2024
@GabrielMartinezRodriguez GabrielMartinezRodriguez deleted the gabriel/chore-change-orm branch December 6, 2024 09:57
This was referenced Dec 13, 2024
This was referenced Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-after-changes Can be merged after requested changes are made

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants