github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #1298] Support references (joins) in adapters, schemas and API routes #26006

New Issue
Closed
opened 2026-04-17 16:23:19 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-17 16:23:19 -05:00
Owner
Copy Link

Originally created by @octet-stream on GitHub (Jan 29, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/1298

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

Few months ago, I've created Mikro ORM adapter for Better Auth. While I was working on the implementation, I found out that there's no way to tell how different models related to each other, and adapter methods being called for each individually from endpoits. This make it impossible to utilize full potential of ORMs (and SQL), which usually have joins one way or another. Having a way to use references will unlock more complex queries, less unnecessary roundtrips and easier support for transactions. For example, in Mikro ORM transactions can be implicit, and for insert operations the query is wrapped into one once EntityManager.flush() called (see docs: https://mikro-orm.io/docs/entity-manager), plus new rows can use nested objects, and arrays so related data can also be inserted in one query. And this is not unique feature for Mikro ORM: for instance, Prisma have similar feature in their create method: https://www.prisma.io/docs/orm/prisma-client/queries/crud#create

Describe the solution you'd like

What I think needs to be done is:

  1. Add joins or references to Adapter interface methods. I'm not sure what the best way would be, but I think this can be done by adding joins or references parameter to some of the methods (like create, findOne, and findMany), which will hold a collection with following params: type with information about what type of a reference it is (1:1, 1:m, m:1, or m:n); model which is the name of referenced model, data I'm not sure about this one yet, but it would provide some way specify the data that need to be inserted or found (for where clauses); Maybe joins (or references) in case if there's more nested references.
  2. Add a way to define references in schema - this should help to implement createSchema support in custom adapters, again, because I could get this information and generate references for Mikro ORM entities (in my case).
  3. Refactor Better Auth endpoints to rely on this new behavior. For example, in email and password signIn you fetch user, then verify if it was found, then fetch for the user's account, then verify it, then verify their password. With joins you can send just one query for both user and their account (plus you can specify what kind of the account to find), and then you can just verify the data. Methods like signUp can also be refactored to use joins, then instead of createUser + linkAccount you can do this in one operation - createUser.

Describe alternatives you've considered

I haven't considered alternatives.

Additional context

No response

Originally created by @octet-stream on GitHub (Jan 29, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/1298 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Few months ago, I've created [Mikro ORM adapter](https://github.com/octet-stream/better-auth-mikro-orm) for Better Auth. While I was working on the implementation, I found out that there's no way to tell how different models related to each other, and adapter methods being called for each individually from endpoits. This make it impossible to utilize full potential of ORMs (and SQL), which usually have joins one way or another. Having a way to use references will unlock more complex queries, less unnecessary roundtrips and easier support for transactions. For example, in Mikro ORM transactions can be implicit, and for insert operations the query is wrapped into one once `EntityManager.flush()` called (see docs: https://mikro-orm.io/docs/entity-manager), plus new rows can use nested objects, and arrays so related data can also be inserted in one query. And this is not unique feature for Mikro ORM: for instance, Prisma have similar feature in their create method: https://www.prisma.io/docs/orm/prisma-client/queries/crud#create ### Describe the solution you'd like What I think needs to be done is: 1. Add joins or references to `Adapter` interface methods. I'm not sure what the best way would be, but I think this can be done by adding `joins` or `references` parameter to some of the methods (like create, findOne, and findMany), which will hold a collection with following params: `type` with information about what type of a reference it is (1:1, 1:m, m:1, or m:n); `model` which is the name of referenced model, `data` I'm not sure about this one yet, but it would provide some way specify the data that need to be inserted or found (for where clauses); Maybe `joins` (or `references`) in case if there's more nested references. 2. Add a way to define references in schema - this should help to implement `createSchema` support in custom adapters, again, because I could get this information and generate references for Mikro ORM entities (in my case). 3. Refactor Better Auth endpoints to rely on this new behavior. For example, in email and password [signIn](https://github.com/better-auth/better-auth/blob/5f34c5fc0d3c3415d639bfed8333d46363d7ddc4/packages/better-auth/src/api/routes/sign-in.ts#L328) you fetch user, then verify if it was found, then fetch for the user's account, then verify it, then verify their password. With joins you can send just one query for both user and their account (plus you can specify what kind of the account to find), and then you can just verify the data. Methods like [signUp](https://github.com/better-auth/better-auth/blob/d75d8b6baa408af5b5172f60006183c5b1d6b7fb/packages/better-auth/src/api/routes/sign-up.ts) can also be refactored to use joins, then instead of `createUser` + `linkAccount` you can do this in one operation - createUser. ### Describe alternatives you've considered I haven't considered alternatives. ### Additional context _No response_
GiteaMirror added the locked label 2026-04-17 16:23:19 -05:00
GiteaMirror commented 2026-04-17 16:23:20 -05:00
Author
Owner
Copy Link

@octet-stream commented on GitHub (Apr 21, 2025):

Hey @Bekacru I see you're making progress on this problem, but at least one thing is missing: the references don't have any info about the kind (at least one of 1:1, 1:m and m:n)

<!-- gh-comment-id:2818488803 --> @octet-stream commented on GitHub (Apr 21, 2025): Hey @Bekacru I see you're making [progress](https://github.com/better-auth/better-auth/blob/b2852227dd0ad74f6f90241492ab8a48d849c49a/packages/better-auth/src/db/field.ts#L56-L75) on this problem, but at least one thing is missing: the references don't have any info about the kind (at least one of 1:1, 1:m and m:n)
GiteaMirror commented 2026-04-17 16:23:21 -05:00
Author
Owner
Copy Link

@Nickersoft commented on GitHub (Jun 8, 2025):

Just came across this and was sad to see it does seem to be fully supported – @Bekacru what is the status of this feature? Are there any known workarounds? I'm trying to JOIN my user model with another table to get some additional info so I don't have separate query calls all across my codebase 😭

<!-- gh-comment-id:2954317208 --> @Nickersoft commented on GitHub (Jun 8, 2025): Just came across this and was sad to see it does seem to be fully supported – @Bekacru what is the status of this feature? Are there any known workarounds? I'm trying to JOIN my user model with another table to get some additional info so I don't have separate query calls all across my codebase 😭
GiteaMirror commented 2026-04-17 16:23:21 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 7, 2025):

Hi, @octet-stream. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary

  • You requested support for references (joins) in Better Auth's adapters, schemas, and API routes to enable complex queries and efficient transactions.
  • You suggested extending the Adapter interface and schema definitions to include join/reference parameters.
  • You noted that current progress by @Bekacru lacks clarity on the types of references (1:1, 1:m, m:n).
  • Another user expressed interest and inquired about the feature's status and possible workarounds.

Next Steps

  • Please let me know if this feature is still relevant to the latest version of better-auth by commenting on this issue.
  • If I do not hear back within 7 days, I will automatically close this issue.

Thank you for your understanding and contribution!

<!-- gh-comment-id:3263870677 --> @dosubot[bot] commented on GitHub (Sep 7, 2025): Hi, @octet-stream. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary** - You requested support for references (joins) in Better Auth's adapters, schemas, and API routes to enable complex queries and efficient transactions. - You suggested extending the Adapter interface and schema definitions to include join/reference parameters. - You noted that current progress by @Bekacru lacks clarity on the types of references (1:1, 1:m, m:n). - Another user expressed interest and inquired about the feature's status and possible workarounds. **Next Steps** - Please let me know if this feature is still relevant to the latest version of better-auth by commenting on this issue. - If I do not hear back within 7 days, I will automatically close this issue. Thank you for your understanding and contribution!
GiteaMirror commented 2026-04-17 16:23:22 -05:00
Author
Owner
Copy Link

@octet-stream commented on GitHub (Sep 7, 2025):

I don't see any progress on this issue. It is still relevant, and I haven's seen any response from maintainers since I've opened it.

<!-- gh-comment-id:3263888066 --> @octet-stream commented on GitHub (Sep 7, 2025): I don't see [any progress](https://github.com/better-auth/better-auth/blob/5f996ad62b5be32d62c6287ce1d9821a58e8cd75/packages/better-auth/src/db/field.ts#L64-L83) on this issue. It is still relevant, and I haven's seen any response from maintainers since I've opened it.
GiteaMirror commented 2026-04-17 16:23:23 -05:00
Author
Owner
Copy Link

@Deali-Axy commented on GitHub (Oct 2, 2025):

@octet-stream Thank you for providing the mikro-orm-adapter. I also really like mikro-orm. If the better-auth official project doesn't have a corresponding solution, I might have to switch to auth.js.

<!-- gh-comment-id:3362111962 --> @Deali-Axy commented on GitHub (Oct 2, 2025): @octet-stream Thank you for providing the mikro-orm-adapter. I also really like mikro-orm. If the better-auth official project doesn't have a corresponding solution, I might have to switch to auth.js.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#26006
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?