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

[moishinetzer]

Relational API 2 has now shipped, how do I run a query like this with ALL or SOME and I'm not referring to exists which still needs joins and does not filter the parent query.

[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})

[howells]

I might have missed something but just wondered what the general timeline for this was now? Excited to use it but would rather wait until it's generally available.

[jdgamble555]

I would like to see this for inserts, updates, etc too!

[bnussman]

Is there a way to "count" using the new where syntax?

[aleclarson]

In the meantime, I've released drizzle-plus with a module that adds a count method to the RQB v2 API:

pnpm add drizzle-plus

Just import this module and you can use db.query.foo.count()

// Postgres
import 'drizzle-plus/pg/count'

// MySQL
import 'drizzle-plus/mysql/count'

// SQLite
import 'drizzle-plus/sqlite/count'

[bnussman]

$count is still using the old syntax in 1.0.0-beta.2 🥀

Am I missing something?

I'd like to be able to "count" using the new "where" object syntax

[aleclarson]

(Not sure if this discussion is monitored anymore)

But, what's the reason for supporting foo: { isNull: true } instead of foo: null in where conditions?

[TGTGamer]

(not part of the team, outsider looking in - drizzle team will correct me if wrong :) )

So to my understanding is that drizzle uses truthy checks as part of it's setup - and therefore you can do something like

{
	where: {
		someChildRelation: false
	}, 
	with: {
		someChildRelation: true // <-- not sure you actually need this :)
	}
}

Which allows you to do rather complex queries building with truthy values. Parsing null, and undefined values in here could cause issues with the SQL generation step creating the wrong output. I've used the Query builder in some rather advanced "wierd" ways myself, and truthy checking, was a super beneficial factor in my implementation I could rely on.

Another factor will be the fact that drizzle is trying to be a universal ORM, and it is much easier to implement complex SQL queries for multiple engines when you haven't got nullable values being passed around you need to account for - you know that the value of foo is either a comparible type (e.g. bar) or an object that defines the comparison.

A quick reminder that in javascript, if you do:

let a;

if (a == null) {
console.log("a is null or undefined"); <-- will be printed
}

if (a === null) {
    console.log("b is null");
} else {
    console.log("b is undefined"); // <-- will be printed
}

a = null;

if (a === null) {
    console.log("b is null"); // <-- will be printed
} else {
    console.log("b is undefined"); 
}

So to check for null, you have to use strict equality, which is a lot of === to be double checking every time you implement a new component into the query pipeline, which is especially difficult on contributors who are unlikely to know to do this by default.

Finally, having built a module extending drizzle ORM to work with my sql client, sometimes' it's really not obvious where the data is actually coming from without a lot of knowledge about the codebase. So I think it also is also a developer ease choice. It simplifies both the developer "why is this null/undefined" problem and the reviewer workload.

[aleclarson]

I see a brief mention in the OP about nested relation filtering. Can you go into more detail about the direction you guys are taking on that?

Preferably, it would mirror Prisma's approach, with its some, every, none filters. See the first example in the following link, where only users with at least 1 published post are returned.

https://www.prisma.io/docs/orm/prisma-client/queries/filtering-and-sorting#filtering

[TGTGamer]

So I'm not digging deep into this, but just to take their first example - this is the equivalent in drizzle:

const result = await drizzle.query.user.findMany({
	where: {
    	email: {
      		ilike: '%prisma.io',
    	},
    	posts: {
       		published: true,
    	},
  },
  with: {
    	posts: {
      		where: {
        		published: true,
      		},
    	},
  },
})

which would result in the same output of

• Returns all User records with
  • an email address that ends with prisma.io and
  • at least one published post (a relation query)
• Returns all User fields
  • Includes all related Post records where published equals true

Drizzle tries - and mostly - succeeds at being SQL-like with all of it's operations (the queries api being an exception), making it easy to switch between SQL and drizzle, which has a lot of benefits explained rather well here: https://orm.drizzle.team/docs/overview#why-sql-like

[aleclarson]

For anyone curious about how to mimic Prisma's filters:

Some

// Is at least 1 post published at or after July 6th, 2025?
where: {
  posts: { publishedAt: { gte: '2025-07-06' } }
}

None

// Are there 0 posts published at or after July 6th, 2025?
where: {
  NOT: {
    posts: { publishedAt: { gte: '2025-07-06' } }
  }
}

Every

// Are all posts published at or after July 6th, 2025?
where: {
  NOT: {
    posts: {
      NOT: {
        publishedAt: { gte: '2025-07-06' }
      }
    }
  }
}

[nahtnam]

Is there a beta version of drizzle-seed?

[NickBeukema]

I can see on npm that there is a "beta" release, but having issues getting everything wired in correctly.

https://www.npmjs.com/package/drizzle-seed/v/0.3.1-84d9a79

Type checking seems to be upset when using the new Relational API, or maybe I'm setting it up incorrectly. I'm following the docs on the beta site and they don't seem to work. Curious if anyone else has gotten it to wire up.

[siamahnaf]

There is no recent activity on Relational API v2, Last beta release was on 3 month ago. When we will get this juicy features in stable release, eagerly waiting.

[AlexBlokh]

it is, we we're rewriting types ground up over the coarse of the past 6 weeks to make it snappy fast and make defineRelations splittable, finishing soon

[hayes]

Is there anywhere this is publicly testable?

I am assuming that I will have to make some significant changes to https://pothos-graphql.dev/docs/plugins/drizzle which integrates relatively deeply with the types

[ProgramYourFace]

This new V2 API is pretty incredible! Unfortunately, I didn't realize this initiative was in progress and so I was building a plugin I was calling drizzle-graph with a similar API as an extension to the V1 Relations API 😆.

Here's a basic example of a documents -> groups (herarchical) -> users schema and it's relations.

// graph.ts
import * as schema from "./schema";
import { createGraph } from "..";

// Graph schema definition
export const documentGraph = createGraph(schema, {
  documents: {
    viewer: {
      or: [
        { from: 'owningUsers'},
        { from: { owningGroup: { target: 'member' } } },
      ]
    },
  },
  groups: {
    member: {
      or: [
        { from: { members: { target: { from: 'user' } } } },
        // Similar to .through in V2
        { from: { parents: { target: { from: { parentGroup: { target: 'member' } } } } } },
      ],
    },
  },
});

// Graph client usage
const db = drizzle.mock({ schema })
const graphClient = documentGraph.connect(db);

// This would then build and execute a recursive query searching for all of the 'users' that have the relation 'viewer' on the document with id 1. 
await graphClient.listSubjects({ type: 'documents', id: 1 }, 'viewer', 'users', {
  columns: {
    id: true
    name: true,
  },
  //Full pagination and filtering support.
  limit: 10,
  offset: 5,
  where: sql`...`,
});

I don't want to start a new issue (since there's already 1.4k), but since I am going to have to rethink my implementation from the ground up anyway once this V2 API releases, I wonder if any of the features I was working on would be in scope for drizzle itself?

Essentially, drizzle-graph was supposed to be an SQL based implementation of the "Relationship Based Access Control" (ReBAC) model that Google proposed in their Zanzibar paper, the main difference being that instead of a dedicated tuple table it would use the relationships that already exist in an SQL database and would also support bi-directional subject-object relationships, and the ability to treat anything as an object or subject.

The inclusion of the .through function in V2 makes traversing junction tables one step easier, but I wonder if drizzle could some day natively handle more remote and recursive relationships to enable complex behaviors like authorized pagination at the database level for hierarchical relationships. Or is such a thing out of scope?

Here is the schema.ts used in the above example to help clarify things:

// schema.ts
import { relations } from "drizzle-orm";
import { integer, sqliteTable, text } from "drizzle-orm/sqlite-core";

export const users = sqliteTable("users", {
  id: integer("id", { mode: "number" }).primaryKey({ autoIncrement: true }),
});
export const usersRelations = relations(users, ({ one, many }) => ({
  groupMembers: many(groupMembers),
}));

export const groups = sqliteTable("groups", {
  id: integer("id").primaryKey(),
});
export const groupRelations = relations(groups, ({ many }) => ({
  documents: many(documents),
  members: many(groupMembers),
  // A group can have one parent
  parents: many(groupParents, { relationName: "child" }),
  children: many(groupParents, { relationName: "parent" }),
}));

export const documents = sqliteTable("documents", {
  id: integer("id").primaryKey(),
  title: text("title"),
  owningGroupId: integer("owning_group_id").references(() => groups.id),
  owningUserId: integer("owning_user_id").references(() => users.id),
});
export const documentRelations = relations(documents, ({ one }) => ({
  owningGroup: one(groups, {
    fields: [documents.owningGroupId],
    references: [groups.id],
  }),
  owningUsers: one(users, {
    fields: [documents.owningGroupId],
    references: [users.id],
  }),
}));

export const documentAssignments = sqliteTable("document_assignments", {
  id: integer("document_id").references(() => documents.id),
  assignee_id: integer("assignee_id"),
  title: text("title"),
  owningGroupId: integer("owning_group_id").references(() => groups.id),
});

// Join table for users -> groups
export const groupMembers = sqliteTable("group_members", {
  id: integer("id").primaryKey(),
  userId: integer("user_id").references(() => users.id),
  groupId: integer("group_id").references(() => groups.id),
});

export const groupMembersRelations = relations(groupMembers, ({one}) => ({
  user: one(users, {
    fields: [groupMembers.userId],
    references: [users.id]
  }),
  group: one(groups, {
    fields: [groupMembers.groupId],
    references: [groups.id]
  })
}))

// Self-referencing join table for groups -> groups
export const groupParents = sqliteTable("group_parents", {
  id: integer("id").primaryKey(),
  childGroupId: integer("child_group_id").references(() => groups.id),
  parentGroupId: integer("parent_group_id").references(() => groups.id),
});

export const groupParentsRelations = relations(
  groupParents,
  ({ one }) => ({
    parentGroup: one(groups, {
      fields: [groupParents.parentGroupId],
      references: [groups.id],
      relationName: "parent",
    }),
    childGroup: one(groups, {
      fields: [groupParents.childGroupId],
      references: [groups.id],
      relationName: "child",
    })
  })
);

[raghav-kukreti]

https://github.com/Laci556/RebaTS
Have you seen this? Uses the v2 api for implementing ReBAC (seems to be very alpha though)

[ridhwaans]

what's the latest on the merge efforts?
do you need a hand in adding new docs?
I'm still interested in the ability to allow sorts, filters, conditionals in joins (with relations)

example

const query = db.query.albumsTable
            .findMany({
              with: {
                artists: {
                  with: {
                    artist: true,
                  },
                },
                songs: {
                  orderBy: (songs, { asc }) => [asc(songs.trackNumber)],
                  with: {
                    artists: {
                      with: {
                        artist: true,
                      },
                    },
                    album: true,
                  },
                },
                genres: {
                  with: {
                    genre: true,
                  },
                },
              },
            })
            .prepare();
          queryResult = await query.execute();

[barnesoir]

+1 for ordering on relationships, bit of a hack to do sub_q or sql back into relational types at the mo

[jerryseigle]

Maybe would be nice to add a query method all this way we don't have to use the with method. It would just automatically get all relational tables and there data

[davbrito]

If I want to order by an extra column, I have to manually write the sql alias, therefore there is no type safety when using extra columns there.

const items = await db.query.posts.findMany({
  extras: {
    distance: (table) => sql<number>`(${table.title} <-> ${searchText})`.as("distance"),
  },
  where: {
    RAW: (table) => sql`${table.title} % ${searchText}` },
  },
  limit: 10,
  orderBy: (table, { sql, asc }) => asc(sql.identifier('distance')),
});

I would like to be able to do domething like:

  orderBy: { distance: 'asc' }
  // or
  orderBy: (table, { asc, extras }) => asc(extras.distance),

[jofflin]

What is the current state on this topic? Are there any updates?

[jofflin]

FYI: If anyone needs guidance, we are already using this in a production SaaS without any issues so far (although my use-case is pretty simple and nothing to crazy)

[AlexBlokh]

we're going through all issues on GH now an fixing them on alternation-engine branch, we're now focused on removing all/most papercuts and getting closer to v1

[jofflin]

Nice, thanks for the update. Appreciate it!

[ProgramYourFace]

Is it safe to say that the alternation-engine branch is the closest to v1 beta for now?

[AlexBlokh]

yes

[jamiemcinnes]

Hi, love this new version. Quick question.

Wondering if this is the only way to query jsonb data on findMany...
RAW: (table: any) => sql(${table.meta} ->> 'ageMin')::int >= ${2}

This works for equals but can't get gte to work...
meta: {arrayContains: { ageMin: 2 } }

[ProgramYourFace]

Any update on when this will be released?

[Frost7994]

It was my own fault I didn't remove all the old relation tables. I have tried creating a query that I can't figure out and was wondering if @jofflin could help?

import { db } from "@/lib/db";

type Category = {
  id: string;
};

type Props = {
  categories: Category[];
};

const readQuestions = async ({ categories }: Props) => {
  const query = db.query.questions.findMany({
    with: {
      options: true,
    },
    where: {
      categories: {
        some: {
          id: {
            in: categories.map((category) => category.id),
          },
        },
      },
    },
  });

  return await query;
};

export { readQuestions };

The issue being the some keyword doesnt exist

[jofflin]

Could you provide the complete error message

[davbrito]

@Frost7994 some is not a valid filter for this API I think.

[kdawgwilk]

What happened to the $inferSelect in the beta? We were using that quite a bit and its seems to be broken now after trying to upgrade to the beta

[raghav-kukreti]

@kdawgwilk Even I have encountered type errors after updating to beta.1; I was using it to create a generic base DAO. Fixed it by explicity typing it; though I don't know if it's the correct way.

type Database = NodePgDatabase<typeof schema>;

type TableWithId = PgTable & { id: PgColumn; $inferSelect: { id: unknown }; $inferInsert: unknown };

export class BaseDao<T extends TableWithId> {
  constructor(
    protected db: Database,
    protected table: T,
  ) {}

  async create(data: T["$inferInsert"]) {
    const result = await db.insert(this.table).values(data as any).returning();
    if (!Array.isArray(result) || result.length === 0) {
      throw new Error("Failed to create record.");
    }
    return result[0] as T["$inferSelect"];
  }
}

[MickL]

@AlexBlokh with 1.0 beta, how to get the schema type with relations? Before with schema instead of relations the following was working:

import { drizzle, type NeonDatabase } from 'drizzle-orm/neon-serverless';
import { relations } from '@myworkspace/db';

let db: NeonDatabase<typeof relations>; // <- Doesnt work with relations

export const useDb = (): NeonDatabase<typeof relations> => {
  if (!db) {
    db = drizzle('DATABASE_URL', {
      relations,
      casing: 'snake_case',
    });
  }

  return db;
};