Last 12 weeks ยท 1 commit
4 of 6 standards met
Problem When using (e.g. ) with , the tool was fetching all policies from with no clause. This meant policies belonging to excluded schemas were also fetched and then compared against the schema snapshot โ causing them to be dropped on the next push. Fixes #5329 Fix Added to the in both: This matches the existing pattern used for tables, enums, sequences, and other objects throughout both files. When is empty (no filter), the original unfiltered query is used as fallback. Testing Type-checked with โ no new errors introduced.
Repository: drizzle-team/drizzle-orm. Description: ORM Stars: 33118, Forks: 1228. Primary language: TypeScript. Languages: TypeScript (98.7%), JavaScript (1.3%). License: Apache-2.0. Homepage: https://orm.drizzle.team Topics: bunjs, mysql, nodejs, orm, postgres, postgresql, sql, sqlite, turso, typescript. Latest release: drizzle-kit@0.31.9 (3w ago). Open PRs: 100, open issues: 1500. Last activity: 3h ago. Community health: 87%. Top contributors: AndriiSherman, dankochetov, L-Mario564, AlexBlokh, Sukairo-02, Angelelz, AleksandrSherman, OleksiiKH0240, RomanNabukhotnyi, realmikesolo and others.
TypeScript
Feature hasn't been suggested before. [x] I have verified this feature I'm about to request hasn't been suggested before. Describe the enhancement you want to request Summary Since Cloudflare Durable Objects only allow us to have one SQLite instance per Durable Object, we are forced organize our data such that all belongs to this single database, even if that wouldn't be the ideal architectural decision. To solve this we should allow the migration code to take the migration table as a parameter so that we can support multiple migration tables in a single Durable Object. Exemplification of the Problem For example: Say you have a team of developers that work on everything related to And another team of developers that work on everything related to In an ideal architecture, these teams would have their own [use whatever modularization term you prefer] and they would be able to isolate the complexity and context of the code to only the domain they work on. Unfortunately, if we're using Durable Objects, that all must be stored in a single SQLite database. So instead of each of these dev teams having their own database to manage, they now need to work on the same database and define their scope based solely on which database _tables_ each team is responsible for. Drizzle could facilitate that by allowing each of these two teams to maintain their own Drizzle definitions and migrations. This is actually pretty easy to do, we just need to allow the function from to support as a parameter (similar to how other implementations of already work).