bigman80
Explore posts from serversDTDrizzle Team
•Created by bigman80 on 5/1/2024 in #help
Typescript performance in larger codebases?
Hey, I've been using drizzle with small projects, but now I'm thinking of migrating a larger codebase to drizzle. This codebase connects to a database with over 500 tables and consists of over 300k lines of code, most of which is SQL queries made with Knex. However, I'm a little concerned about typescript performance degrading at that scale. I know a common recommendation is to break up the code into smaller pieces, but unfortunately that won't be possible right now.
I started incorporating Kysely into this codebase, but type checking and autocomplete became much slower. Looking at the way drizzle works I'm hoping that it could put less strain on the type checker and be more viable. Can anyone with experience using drizzle at that scale let me know how the typescript experience and overall type-checking performance is for them?
1 replies
Does the TypeScript performance scale with larger projects?
I just started migrating to kysely, love it so far! I was wondering how well the TypeScript performance scales for medium to large projects. For example, I'm working on a project with 500 db tables and 600k lines of code with much of it composed of db queries. As I'm rewriting the first few queries, I'm noticing slight delays with type inference and IDE code completion. Nothing major, but I'm worried it might get worse as I migrate more of the project and more type checking needs to happen.
Is this an actual concern or am I overthinking it? Can anyone who is using kysely on a larger project attest to whether they're running into type performance issues?
7 replies
DTDrizzle Team
•Created by bigman80 on 12/28/2023 in #help
Running complex migrations
I'm a little confused on how to run more complex migrations like backfilling or splitting tables.
Say for a todo app I have a
users table with columns id and todo_body. Now I want to split that table into separate users and todos tables to have a many-to-many relation.
Currently we're using knex, so in the knex migration file first I'd create the new table, then backfill existing todos into the new table, then drop the columns of the existing table.
In drizzle, it looks like I should first make the changes to the schema, then generate migrations files using drizzle-kit, then manually edit the migration files to add the backfill step.
But what I don't understand is how does drizzle track migrations and make sure that it doesn't run the backfill more than once? It seems to me like when you run migrations through the migrate() helper, it runs all the migrations every time. This is because drizzle doesn't store the state of which migrations have run in a database table like knex. So every time I run the migration helper, it would try to backfill.
This is just one example of a case requiring backfill, but another I can think of is if I need to add a new not nullable foreign key to an existing table.
What is the recommended way of running and keeping track of these migrations?18 replies