exclude models from bundle
Hello!
I have a monorepo (turborepo + pnpm workspaces) with packages database, schemas & contracts and apps web(nextjs 13 app) & api(nestjs app).
Database package hold all the tables, enums & relations definitions using drizzle-orm.
Schemas is using the drizzle-zod to create needed body/query schemas.
Contracts are ts-rest contracts shared between FE and BE....
Migration struggled at some snapshot (existed table), Can I skip it?
As my understanding, Drizzle generate each database changes as snapshot. In my case migrate function was struggled at some snapshot with error like TABLE EXISTS cause I manually create/modify that table myself or it was an existed table before I'm using Drizzle. Now any new schemas can't migrate to database due to it's struggled at that snapshot. Can I skip it or anyway to solve this?
Type Generated from $inferInsert does not change after column type update
I have a table called
identities in a schema called identity. When I changed the phone_country_code column type from text to numeric, the sql generated from drizzle-kit was correct, but the type generated from inferInsert still has the old string type. (see attached image).
```typescript
// Table definition
phoneCountryCode: numeric('phone_country_code').notNull(),
...
push:sqlite cannot find module 'better-sqlite3'
im trying to hook up turso wind drizzle, and encounter thi error,
How do you use 128-bit values with varbinary and what is the fastest way to search for rows?
I have been researching the fastest way to insert data into SQL tables, & I'm having a hard time using Drizzle with PlanetScale because PS doesn't support foreign keys; which means that PS is auto-sharded & the autoincrement primary keys are not going to be the same. You don't want to use UUID because 1.) it exposes your MAC address & 2.) the values don't always increase, i.e. non-monotonic.
The current industry choice is ULID, which uses a 128-bit pattern where you take the JS new Date().getTime() & shift the lower 48-bits into the MSB & the lower 80 bits are a cryptographically-secure random number. (CSRN) generated at runtime.
I don't like the idea of having to pay to generate random numbers at runtime so I created an npm package called linearid (LID) that uses a 128-bit value where the LSB is a 64-bit CSRN created upon server initialization, & the MSB is a 42-bit millisecond timestamp followed by a 22-bit spin ticker that gets reset every millisecond & incremented each time you call LIDNext(). If you call LIDNext() more than 2^22 (4,194,304) times in one millisecond it will spin wait until the next millisecond. This gives you a 128-bit monotonically increasing unique ID that you can use to look up data in SQL tables. Then to search for the SQL row, you extract the seconds timestamp from the LID, & search for the row by date range using the filesystems timestamps so you don't have to do a full table scan. Instead you search through all of the SQL rows created starting at the millisecond the LID was generated to something like three seconds after, which is much faster for searching for iNodes on disk....
