Relational API v2

[AlexBlokh]

We've launched Drizzle Relational Queries exactly a year ago and it's time to ship a fundamental upgrade. We've gathered a massive amount of valuable feedback from the community and going to address every issue, so if you have anything you're missing with Drizzle Queries - feel free to comment below!

Things we want to address:

• relations declaration
• query API with updated filters API and [nested relations filters](Add nested filters for relational queries #1152)
• maintain legacy api for smooth migration
• improved documentation
• UPD: support for Views

Relations declaration

Current implementation of Drizzle Relations has several major flaws - naming, imports, many to many relations, where clause and aggregation fields.

Naming and imports

Our community’ve split into 2 groups - ones that don’t care and others who demand us to reduce the needs for imports whenever possible. We've been using drizzle in production projects and never paid attention or considered amount of imports an issue, we’re on first camp, but as of now we do consider imports to be a decent part of the DX. We took that into consideration while designing API v2.

As of naming - we've originally sticked to fields and references and thought it'd be a good idea to stick to close-to-sql model here, but it turned out to be confusing for both the community and for us too! We've investigated implementations across different libraries and decided to land on one, many, from, to and through for junction tables, they does seem to be the most natural out of all for both newcomers and for developers who're going to migrate to Drizzle.

import { relations } from 'drizzle-orm';
import * as schema from './schema';

export default relations(schema, (r) => ({
  posts: {
    author: r.one({
      from: r.users.id,
      to: r.posts.authorId,
    })
  }
})

New API will let us support aggregation fields in schema declaration

export default relations(schema, (r) => ({
  pets: {
    owner: r.one({
      from: r.pets.ownerId,
      to: r.users.id,
    }),
    count: r.count(), // <---
  },
}));

Where clauses

export default relations(schema, (r) => ({
  users: {
    pikachuPets: r.many({
      from: r.pets.ownerId,
      to: r.users.id,
      where: {
	      petName: "pikachu",
      }
    }),
  },
}));

As of V2 - relations declaration will be defined in one file and relations initialisation function will now require schema and will provide the best possible autocomplete experience with no need to import anything else from other files

With this small restriction we can perfectly solve junction table declaration challenge:

export default relations(schema, (r) => ({
  pets: {
    ownersM2M: r.many({
      from: r.pets.ownerId.through(r.petsToOwners.ownerId),
      to: r.users.id.through(r.petsToOwners.petId),
    }),
  },
  users: {
    petsM2M: r.many({
      from: r.users.id.through(r.petsToOwners.ownerId),
      to: r.pets.ownerId.through(r.petsToOwners.petId),
    }),
  },
}));

and for composite keys

export default relations(schema, (r) => ({
  pets: {
    ownersM2MComposite: r.many({
      from: [
        r.pets.id1.through(r.petsToOwners.petId1),
        r.pets.id2.through(r.petsToOwners.petId2),
      ],
      to: [
        r.users.id1.through(r.petsToOwners.ownerId1),
        r.users.id2.through(r.petsToOwners.ownerId2),
      ],
    }),
  },
  users: {
    petsM2MComposite: r.many({
      from: [
        r.users.id1.through(r.petsToOwners.ownerId1),
        r.users.id2.through(r.petsToOwners.ownerId2),
      ],
      to: [
        r.pets.id1.through(r.petsToOwners.petId1),
        r.pets.id2.through(r.petsToOwners.petId2),
      ],
    }),
  },
}));

Filters API

While Drizzle was originally built as a SQL-like ORM, we quickly got to the point that we need to have best of both(sql and relational) worlds. We’ve introduced relational APIs with the least compromises possible. Based on the community feedback and by using our own library for a while on commercial production grade projects we do came to the conclusion to introduce object based filters for relational queries, it just feels natural

// old version
db.query.pets.findMany({
  where: (pets, { eq }) => eq(pets.ownerId, 1),
});

// new version
db.query.pets.findMany({
  where: { ownerId: 1 }
});

multiple filters are by default combined with AND operator

db.query.pets.findMany({
  where: { ownerId: 1, name: "pikachu" }
});

// translates to
// select ... from pets where ownerId = 1 and name = 'pikachu'

you will be able to combine filters with OR and NOT operator

db.query.pets.findMany({
  where: { NOT: { userId: 1 } }
})

db.query.pets.findMany({
  where: { OR: [{ ownerId: 1 }, { name: "pickachu" }] }
});

// translates to
// select ... from pets where ownerId = 1 or name = 'pikachu'

scalar types will have either scalar value filter or advanced object filter

where: {
  ownerId: {
	  eq: ...,
    gt: ...,
    lte: ...,
    not: ...,
    
    or: [1,2,3]
    or: [{ gt: 1 }, { lt: 3}]
    or: [1, { lt: 3}]
    // etc...
  }
}

this API will let us easily introduce relational filters while keeping the option to declare raw sql filters for whatever cases we do not support on launch day

db.query.pets.findMany({
  where: { owner: { id: 10 } }
});

db.query.pets.findMany({
  where: {
    RAW: (pets, { sql }) => sql`lower(${pets.petName}) like 'pikachu'`,
  }
});

Interoperability and Docs

As of now Queries section of the docs is a zero to hero of Relational Queries and we will split it into two detailed sections on how to declare relations and how to query

As of interop - we will add a legacy drizzle._query operator to establish a smoother transition on existing projects with the ability to either stay on legacy API or gradually migrate

[driwand]

Great news! was looking forward to the nest filter for a long time. There is one issue I faced using the current query and it's related to this issue#1378 hoping to see it fixed!

[firtoz]

Looking great!

One comment:

db.query.pets.findMany({
  where: { ownerId: 1, name: "pikachu" }
});

db.query.pets.findMany({
  where: { NOT: { userId: 1 } }
})

db.query.pets.findMany({
  where: { OR: [{ ownerId: 1 }, { name: "pickachu" }] }
});

These feel too similar, would it be better or worse to use something like a dollar prefix or some other indicator that highlights that "NOT / OR mean something special here and it's not a field"

I'm new to Drizzle (loving it so far) so I don't know much about the history or the ongoing conversations - if a dollar prefix or some other "this is a special keyword" indicator was considered already and decided against, fair enough

[AlexBlokh]

we've discussed this internally during planning and specifically landed on NOT and OR

[AlexBlokh]

$ syntax in drizzle is currently represents a non-sql / runtime parts of the API and does not align with query filters

[gruckion]

I hate the use of $ in this case.

[Papooch]

How do you solve the use-case when a column is named after one of the keywords? It's unlikely, but a very real scenarios in legacy tables, where NOT could easily mean something like "number of transactions".

Would you disallow creating table properties with those keywords? Or do some magic on the query side?

[AlexBlokh]

in drizzle you have ts names and database names, so you can call however you want

[B33fb0n3]

I would love to see a better select functionality. I see this:

// old
await db.query.test.findMany({
   columns: {
      field1: true,
      field2: true,
      field3: true
      ...
   }
})

// maybe future
await db.query.test.findMany({
   columns: ["field1", "field2", "field3"] // or something similar
})

Is it just me, or is the composite keys pattern way more complicated than it's available right now?

[AlexBlokh]

current syntax is concise and in line with the rest of the API

[alexcroox]

@AlexBlokh the syntax for relationship query columns is different to non relationship query columns which can be frustrating maintaining 2 seperate column configs for repeated queries.

For example relationship query columns are: { fieldName: boolean }
Non relationship query columns are: { fieldName: schemaField }

Which means I need 2 versions of a common "selectUserSensitiveColumns" object

[AlexBlokh]

you shouldn't be mixing query and select APIs and we don't design them this way, we intentionally separate Query + CRUD everywhere we can so that developers get on board of a new modern paradigm

[alexcroox]

OK another example, when I do an INSERT (which I have to use CRUD for) and I want the same column config for returning(selectUserSensitiveColumns)

[dBianchii]

I usually avoid leaving unnecessary comments that don't add nothing of value to the discussion.

However, just this once....

LETS GOOOO!!! 🎉🎉🎉🚀

[IsaiahByDayah]

This looks great! The only thing that stands out to me is it looks like the from and to fields for relations doesn’t seem to care which table is “from” and which is “to”? In the examples you’ve included, there are relations where the table the relation is scoped to is sometimes from and sometimes to. Is this correct? Do the current fields and references behave the same way and I just never noticed?

example of what I mean (on mobile so excuse size):

besides that I think this is looking great! 👏👏👏

[AlexBlokh]

yeah, ma bad, it will care on the types lvl just like it does now

[14gasher]

This does introduce a vulnerability. Clients may be able to manipulate queries from endpoints.

Sequelize uses symbols to protect against this kind of vulnerability:

‘’’
where: {
[notSymbol]: [{name: “pikachu”}, {name: “jigglypuff”}],
}
‘’’

finally, this prevents the case (rare, but possible) that there is a conflict between column names and “special keywords”

[AlexBlokh]

we will take that into consideration

[rmtmckenzie]

This might not be in the scope of this redesign, but if you're working on the API anyways I'd like to throw in a suggestion.

In my database, I use relations with a primary key that I treat as an implementation detail and have a separate public ID that is used externally (very handy for migrating database providers which have different key requirements). I'm not sure it'd work at all with the new syntax, but rather than doing extra database calls to get the public id -> internal, it'd be awesome to be able to do something like this:

const columns = [ ... ]; 
const withMap = { ... }; 

db.query.purchaseFeedbacks.findFirst({
  columns,
  with: withMap,
  where: and(eq(receipts.publicId, receiptPublicId), eq(users.publicId, userPublicId)),
  joins: [
    { table: receipts, on: eq(purchaseFeedbacks.receiptId, receipts.id), type: 'inner' },
    { table: users, on: eq(receipts.userId, users.id), type: 'inner' },
  ],
});

It's super useful to be able to use the query for this rather than the more sql-like syntax as the columns & withMap are parsed from a graphql request - this same operation would take at least a few hundred lines of code if I had to write it all out more explicitly.

The idea of what I've done above is that tables which are specified in the joins are not read from directly but rather used exclusively for the where clause as any data being read is specified in the columns/with. There may be a more elegant way to do this, but it's what I came up with.

I've been using a very basic implementation of this in a fork (https://github.com/rmtmckenzie/drizzle-orm/tree/query-joins-v2) but it's definitely not production ready and only implemented for mysql and postgres. It seems like your proposed changes will make this less possible, but if this sparks any ideas I'd appreciate it being considered. (and feel free to lift any code in that branch if it's at all helpful).

[rmtmckenzie]

I can paste in the relevant part of my schema if it would help make sense of that

[AlexBlokh]

you should submit that as a separate discussion, I suppose

[JakeGinnivan]

Love the relations changes, the relations API currently is pretty hard to get right when first starting. The new filters API conversion from Prisma projects far easier, my concern with the new filters API is the TypeScript performance on a larger project.

Prisma has a codegen step to create the types which would help the approach scale due to less computed types. The current drizzle approach is great from a TypeScript performance point of view, it also it super easy to extract helpers and compose bits of queries together which getting the types right to store parts of queries in variables is pretty hard with the object syntax.

It could be good to have an opt out which ensures the types are not included at all for these relations in the case of build performance issues? Unsure if just having those types could impact build performance or you have to use the new syntax to be impacted.

At any rate, suggest checking the build perf ( of a large project before/after upgrading to a version with the filters API, then converting a number of queries across then checking build perf again. Once it's released it might be a lot of work to fix large perf issues without breaking changes.

[AlexBlokh]

if you don't use legacy ones - they don't compute

[JakeGinnivan]

I was more thinking for the new types. Even if you are using the old API, the types for the new query API will be in your type graph.

Just saying, this approach may struggle being inferred the whole way down and could end up needing a code gen step to get decent perf. Should just do some initial benchmarking to see the impact on compilation times before committing.

Could be good to decouple the various parts of this, so if the query api has build perf impacts, the improved relations can still be shipped.

[AlexBlokh]

we always have an ace in the sleeve for the types, we're friends with David Blass, who's a TS guru and author of ArkType

[AlexBlokh]

if there be any struggle with perf - we gonna fix them, mark my word!

[L-Mario564]

New API will let us support aggregation fields in schema declaration

export default relations(schema, (r) => ({
  pets: {
    owner: r.one({
      from: r.pets.ownerId,
      to: r.users.id,
    }),
    count: r.count(), // <---
  },
}));

What does r.count() do exactly here? How would I use the count property in a query?

Where clauses

export default relations(schema, (r) => ({
  users: {
    pikachuPets: r.many({
      from: r.pets.ownerId,
      to: r.users.id,
      where: {
	      petName: "pikachu",
      }
    }),
  },
}));

In the where clause example above, does that mean I can query the above relation like this?:

db.query.users.findFirst({
  columns: {
    // ...
  },
  with: {
    pikachuPets: {
      columns: {
        // ...
      }
    }
  }
});

[dankochetov]

The example for count() is misleading, it will be used in the query API, not in the declaration API.

In the where clause example above, does that mean I can query the above relation like this?:

yes

[kenn]

Great updates. Just a small nit:

As of interop - we will add a legacy drizzle._query operator to establish a smoother transition on existing projects with the ability to either stay on legacy API or gradually migrate

Wouldn't it make more sense to have it reverse with a config option? For instance:

// Start migrating

export default {
  query: 'legacy' // tentatively swap the assignment
} satisfies Config

db.query.pets.findMany // legacy
db._query.pets.findMany // v2

↓

// Almost finished transition to v2

export default {
  query: 'v2' // default
} satisfies Config

db._query.pets.findMany // legacy
db.query.pets.findMany // v2

[dankochetov]

drizzle-orm currently doesn't use the config file at all, it's for drizzle-kit only. Also, since we don't rely on codegen, it would be a relatively big change in the types to swap .query and ._query based on a config flag. So we've settled on a compromise which allows you to do find-and-replace db.query -> db._query across your codebase to postpone the migration to V2 (although the query API changes will be minimal compared to the declaration API, so a lot of queries will work with V2 without any changes).

[413n]

I don't know if this is already included in your changes, but will you include the possibility to have optional one() relations (#1066)?

[AlexBlokh]

yes, will cc: @dankochetov just to make sure

[413n]

Will the where clause be available also for the r.one relations?

export default relations(schema, (r) => ({
  users: {
    pikachuPets: r.many({ 
      from: r.pets.ownerId,
      to: r.users.id,
      where: {  // <--- This
        petName: "pikachu",
      }
    }),
  },
}));

[AlexBlokh]

yes, will cc: @dankochetov just to make sure

[ivstiv]

I am sure you have considered it seeing you have mentioned a "through" relation, but I want to point out the importance of polymorphic relations when designing the DX. These discussions have some good insights.

• [FEATURE]: Support Polymorphic Association #1051
• [FEATURE]: Customizable many relations #674

Exciting stuff!

[AndriiSherman]

Sure, it's included

[AndriiSherman]

This is an example from a discussion description

export default relations(schema, (r) => ({
  users: {
    pikachuPets: r.many({
      from: r.pets.ownerId,
      to: r.users.id,
      where: {
	  petName: "pikachu",
      }
    }),
  },
}));

[gruckion]

What does this become in sql?

[dankochetov]

a large query

[Deliana90]

when buddy? ^_^

[jakeleventhal]

One thing I would really hope to see in V2 that has been a pain point for me and has prevented me from using the V1 RQB is the lack of the ability to use where conditions that rely on related tables.

For example:
I have a table listings that has many listingVariants. I want to make a query on the listings table where all of its variants have isNotNull(listingVariants.productId).
The way I am currently accomplishing this is like so:

db
  .select({ id: listings.id })
  .from(listings)
  .leftJoin(listingVariants, eq(listingVariants.listingId, listings.id))
  .where(
    exists(db.select().from(listingVariants).where(and(eq(listingVariants.listingId, listings.id), isNotNull(listingVariants.productId))))
  )

This is annoying since it requires manually joining and using subqueries. This same problem gets even more complicated when my with statements require json_agg and I have to do all that logic myself rather than relying on the RQB. It would be much easier if I could mention related tables in where clauses nested inside with clauses. For example, I would want to be able to make the same query like so:

db.query.listings.findMany({ where: {
  ALL: { variants: { productId: { NOT: null } } }
}});

[AlexBlokh]

yes, that is included

[khuezy]

Sorry if this was discussed above but I skimmed through and didn't find anything. Would this new API allow to infer the type for the relation query?

eg:

const postRelations = relations(posts, ({ many }) => ({
  comments: many(comments)
})

// How do I create the types for this query?
db.query.posts.findMany({
   with: { comment: true}
})

[sillvva]

It would be nice if they had this InferQueryModel type helper built in

import * as schema from "$server/db/schema";
import type { BuildQueryResult, DBQueryConfig, ExtractTablesWithRelations } from "drizzle-orm";

type TSchema = ExtractTablesWithRelations<typeof schema>;
export type QueryConfig<TableName extends keyof TSchema> = DBQueryConfig<"one" | "many", boolean, TSchema, TSchema[TableName]>;
export type InferQueryModel<TableName extends keyof TSchema, QBConfig extends QueryConfig<TableName> = {}> = BuildQueryResult<
	TSchema,
	TSchema[TableName],
	QBConfig
>;

/**
 * Usage
 */
type Result = InferQueryModel<
  "logs",
  {
    columns: { id: true },
    with: {
      character: {
        columns: { id: true }
      }
    }
  }
>;

// type Result = { id: string; character: { id: string; } }

[khuezy]

I currently do this, but it's still not 100% right, eg:

type UnwrapPromise<T> = T extends Promise<infer U> ? U : T;

export type PostQuery = UnwrapPromise<ReturnType<typeof getPosts>>

export async function getPosts(id: string) {
   return db.query.posts.findMany({
      with: { comments: { comment: true }}
   })
}

This should work, but drizzle returns a weird type:

comments: (string & { comment: string}}

I'm not sure why the return type of the query has the string &... if it didn't include that then everything is good.

[sillvva]

You can also use Awaited<ReturnType<typeof getPosts>>. Awaited is a built-in helper

[khuezy]

type RemoveStringAnd<T> = T extends string & infer U ? U : { [K in keyof T]: RemoveStringAnd<T[K]> };

export type PostsQuery = RemoveStringAnd<Awaited<ReturnType<typeof getPosts>>>

This gets rid of the annoying (string & wrapper and returns the expected type.
Edit: but strings now become unknown 😢

This should work:

type RemoveStringAnd<T> = T extends string & infer U
  ? U extends object
  ? U
  : T
  : {
    [K in keyof T]: RemoveStringAnd<T[K]>;
  };

[khuezy]

Ok, I finally figured out why I was getting the weird typing, it's because my schema had the same name as my relation field. Looks like it concats the 2 types.

eg:
schema:

author: text('id')

relation:

author: one(author, {...

query:

with: {
   author: true
}

This results in (string & {what ever type the relation query is})

[septatrix]

I have no problems with the relational API moving a bit further away from vanilla SQL nomenclature. The relation API is for simple, primitive query so I agree that they should be made as easy as possible.

My biggest gripe, however, is currently the type unsafety of the query builder (#2329). I hope that that will also see some love afterwards and be addressed, maybe a Query Builder V2...? :)

[septatrix]

The issue was converted to a discussion: #2409

Any feedback from people who have run into type issues or experience runtime errors due to wrong inferred types would be appreciated. Similarly, feedback from people who have used alternatives like kysely which are type safe would be appreciated.

It would also help if someone who was with the project from the beginning could comment on the reasons why you apparently turned your backs on such a type safe API.

[kenn]

When I work with relations, I often find myself wanting to ORDER BY the child tables.

When I don't have to sort, it's pretty easy:

with: {
  posts: true
}

But as soon as I want to sort them, suddenly I have to import desc and posts.

with: {
  posts: {
    orderBy: [desc(posts.id)]
  }
}

This works in a simple case, but I have an admin page that handles all tables and their child tables in a common way, and there I want to be able to meta-programming those. (click parent table, drop down relation child tables sorted by timestamp, etc.)

If it was just a string and Drizzle handles them with reflection, just like _.orderBy with lodash, it would make Drizzle super powerful for meta programming. (FWIW it's easy to do this with Rails with ActiveRecord::Relation, which is super power for meta programming)

with: {
  posts: {
    orderBy: ['posts', 'id', 'desc']
  }
}

Better yet, we could have default order defined in the relation itself:

export default relations(schema, (r) => ({
  users: {
    pets: r.many({
      from: r.pets.ownerId,
      to: r.users.id,
      orderBy: [desc(r.pets.createdAt)]
    }),
  },
}))

[dankochetov]

we can make orderBy a callback with asc/desc helpers available I think
it won't be a string because we also allow filtering by SQL expressions

[subodhpareek18]

Currently the query builder as the name suggests is for fetching the data. Are there any plans to have similar syntax for insert/update/... too which requires fewer imports

// current
await db.update(users)
  .set({ name: 'Mr. Dan' })
  .where(eq(users.name, 'Dan'))
  .returning({ updatedId: users.id });

// to something like
await db.update.users({
  where: { name: 'Dan' },
  data: { name: 'Mr.Dan' },
  select: { updatedId: true }
})

or is that not something we could expect going forward, as it's too far away from the sql like roots of drizzle?

[dankochetov]

not on the roadmap for now

[anthonyhoegberg]

Sorry for intruding here.
Is there someplace we can see the progress of the new Relational API V2 specifically and test it etc, while its under development?

[dankochetov]

it's still on early stages at the moment

[cimchd]

This is probably out of scope, but I think this is a problem many projects have to take care of.

If I have a ui that can produce very flexible queries (e.g. a filterable and sortable table), we have to send the query information as a text message (json format) to the api. Then we have to parse the message and convert it into a drizzle query.

If drizzle could support a standardized json compatible format that can be easily converted into a drizzle query (maybe with a helper function) this coud save a lot of time.

[anthonyhoegberg]

Couldnt you just use the drizzle filter argument object as is and treat it as "json"? With smth kinda like JSON.parse() and JSON.stringify()

[cimchd]

For the simple examples from above this seems to be possible. The new API is way better for this usecase than the old one. But I expect that in more complex szenarios there will probably again some helper functions needed for referencing related fields or somethings else?

[CanRau]

Is #1513 still somewhere on some roadmap?

[nelsonprsousa]

Hi 👋
Out of curiosity, will this API, alongside nested filters, be able to provide an API for common table expressions?

Thank you, awesome job!

[dankochetov]

CTEs are already supported in the core API, not sure where can they fit into the relational queries API

[nelsonprsousa]

I wasn't aware of it. The issue is still opened: #209
There's also this PR: #1405

Should both be closed?

[dankochetov]

no, "with recursive" is still not supported, but regular "with" is

[nelsonprsousa]

Oh, okay, I meant "with recursive" initially. But guess that this API has nothing to do with it?

[dankochetov]

yes, it's a different thing

[Hebilicious]

Good job on the v2 design, it's looking good !
Currently we are able to define relations with a relations function for each table, so relations and table definition can be colocated.
With this new design, I understand that this is no longer possible, and all relations must be included in a single relations function, that contains all the database relations.

Am I correct in understanding that we'll have to deal with a gigantic function that can't be split without losing type inference ?

If that's the case, migrating to the new schema would feel like a downgrade for users who currently have their tables split in multiple files with their relations neatly defined next to the table definition.

Could you please consider this ?

Maybe this could potentially be solved with a tableRelations helper :

export const petRelations =  tableRelations(schema, (r) => ({
  pet: {
    ownersM2M: r.many({
      from: r.pet.ownerId.through(r.petsToOwners.ownerId),
      to: r.user.id.through(r.petsToOwners.petId),
    })
  }
}));

export const userRelations = tableRelations(schema, (r) => ({
  user: {
    petsM2M: r.many({
      from: r.user.id.through(r.petsToOwners.ownerId),
      to: r.pet.ownerId.through(r.petsToOwners.petId),
    })
  }
}));

const allRelations = relations({ ...userRelations, ...petRelations })

[itpropro]

We currently have relations and table definitions split colocated in every project, will that still be supported in V2 @AlexBlokh ?

[MattCantor]

How do you colocate your tables with their relations in many files without creating circular dependencies between the files?

[Wundero]

As long as you don't have side-effects, iirc circular file dependencies don't really matter in js. It works just fine in the current V1 api to have circular file dependencies in schema files from what I can tell.

[Hebilicious]

Another solution that is inference friendly be would be the schema builder pattern (this is what pothos does) :

const schema = new PostgresSchema()

const user = schema.table("user", {}, table => {})
const userRelations = schema.relations(table, relations => {})

Granted that would be a bigger shift from v1, but being able to split schema and relations in multiple files is pretty important.

[hayes]

Are there any updates on when this might be landing, or any pre-release/work in progress branches to look at? I've been watching this for a while, because this should enable a much better drizzle plugin for pothos.

I've been pretty focused on other work lately, but the drizzle plugin is back on the top of my priorities, and I am going to be slowly working on it over the next month or 2. I don't think this is strictly a blocker, but nested filters significantly improve how queries can be constructed.

This is probably out of scope, but for nested selections, having the ability to alias selections would be really cool. For example, being able to select drafts and non-drafts from the same post relation

db.query.users.findFirst({
  columns: {},
  with: {
    posts: {
      where: { draft: false }
    },
    'drafts:posts': {
      where: { draft: true }
    }
  }
});
// returns something like [{ posts: [...], drafts: [...] }]

[tslater]

This is really important for complex apps. Obviously you can work around it with multiple queries, but that will require more post-processing and a lot more code.

[jokull]

Concerning one() relationships, I think it should be looking at the presence of references() to determine nullability at the TypeScript level. Just my two cents.

The nullability in TypeScript for one() relationships is determined by how you define the relation in the relations() function. If you don't specify the fields and references in the one() relation, TypeScript will infer that the relation could be null.

This feels like implicit, but it should be explicit. Furthermore, I would have thought fields+references in one() would be important in both null and not null cases to disambiguate relationships pointing to the same table.

[typicode]

Not a blocker to using Drizzle but I sometimes miss query scopes (ex: https://guides.rubyonrails.org/active_record_querying.html#scopes)

Thank you for the hard work.

[kenn]

Yeah, composable scopes are great, like User.active.latest by storing and passing query options as a chain-able proxy object. I think that would live in a higher abstraction on top of Drizzle, though.

[andresgutgon]

We do a kind of scopes this way:

export class UsersRepository extends Repository {
  get scope() {
    return this.db
      .select(getTableColumns(usersTable))
      .from(usersTable)
      .where(eq(usersTable.deletedAt, null)) // I'm lazy this is wrong for sure
      .as('activeUsers')
  }
  
  async function allUsers () {
    // Use the `this.scope` in the `.from`
    return this.db.select().from(this.scope)
  }
}

[andresgutgon]

Wait, I'm not sure if this can be composable. I didn't read your message well. Maybe is there a way not sure

[mianala]

I can't wait anymore guys. Can you please tell us when a beta version of this will be available? I don't want to write V1 anymore after seeing this. Please.

[CptJJ]

Any ETA on this? Ive found it really hard to build paginated apis with drizzle query syntax because there is no way to count to total number for rows in that filter. Im using 3-4 layer deep relations so switching to .select() is not really a good option.

[LeonAlvarez]

what's the issue u find?

[tacomanator]

Would love to see some support for custom sql in the relation definitions, with the hope that I could realize a relation using JSON data with ids.

[LeonAlvarez]

This would be usefull too for stuff like ltree & other custom types, rn I have implemented my own methods to filter on relations mainly because lack of filtering & this

[PhilipGrefe]

Hi Team, I'd like to use the query syntax for (sqlite) views.
Is there any update or thread on the UPD: support for Views that is mentioned in the original post?

export const usersView = sqliteView("user_view").as((qb) => qb.select().from(users))

const resultWithQuerySyntax = dbWithDrizzle.query.usersView.findMany() // not possible atm 🫤

const resultWithSelectSyntax = dbWithDrizzle.select().from(usersView) // working as documented, but no support for querying relations via 'with' from the query syntax