Skip to content

refactor: separate driver-specific find options#7192

Open
B4nan wants to merge 1 commit intomasterfrom
driver-specific-find-options
Open

refactor: separate driver-specific find options#7192
B4nan wants to merge 1 commit intomasterfrom
driver-specific-find-options

Conversation

@B4nan
Copy link
Member

@B4nan B4nan commented Feb 13, 2026

  • Move SQL-only options (groupBy, having, lockMode, lockTableAliases, indexHint, collation, comments, hintComments) out of core FindOptions/CountOptions into SqlFindOptions, SqlCountOptions, etc. in @mikro-orm/sql
  • Move MongoDB-only options (collation as CollationOptions, indexHint as string | Dictionary, maxTimeMS, allowDiskUse) into MongoFindOptions, MongoCountOptions, etc. in @mikro-orm/mongodb
  • SqlEntityManager/MongoEntityManager and their repositories override find/count/stream methods to narrow the options type, so users get driver-appropriate autocomplete and type checking
  • Replace runtime validation (validateSqlOptions, MongoDB string-collation guard) with compile-time type safety — passing a wrong option shape is now a type error instead of a runtime throw
  • Shared base interfaces (SqlQueryExtras, MongoQueryExtras) eliminate property duplication across option variants
  • lockMode (pessimistic) and lockTableAliases are SQL-only on find(); FindOneOptions.lockMode still includes LockMode.OPTIMISTIC for both drivers (versioned entity support)

Breaking changes

  • groupBy, having, lockMode, lockTableAliases, indexHint, collation, comments, hintComments removed from core FindOptions — use SqlFindOptions (available via @mikro-orm/sql and all SQL driver packages)

@codecov
Copy link

codecov bot commented Feb 13, 2026

Codecov Report

❌ Patch coverage is 93.02326% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 99.62%. Comparing base (e350aa1) to head (5c9ff78).

Files with missing lines Patch % Lines
packages/mongodb/src/MongoEntityRepository.ts 66.66% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #7192      +/-   ##
==========================================
- Coverage   99.69%   99.62%   -0.07%     
==========================================
  Files         252      252              
  Lines       22705    22765      +60     
  Branches     6156     6155       -1     
==========================================
+ Hits        22636    22680      +44     
- Misses         69       85      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@B4nan B4nan force-pushed the driver-specific-find-options branch 3 times, most recently from e81ea94 to 5ebde31 Compare February 14, 2026 00:13
@B4nan B4nan force-pushed the driver-specific-find-options branch from 5ebde31 to 5c9ff78 Compare February 14, 2026 08:25
@B4nan
Copy link
Member Author

B4nan commented Feb 14, 2026

Thoughts about this @xcfox @boenrobot? I am a bit torn here. I like the outcome, but I don't like the implementation very much.

@boenrobot
Copy link
Collaborator

I'm not a big fan of all the "as any" casts going on, even if they are just internal, rather than at the public api surface.

I think every time you hit one, you're really exposing some design flaw. Not sure how to addrees them though... Not from the quick skim so far at least.

@B4nan
Copy link
Member Author

B4nan commented Feb 14, 2026

We don't really depend on 3rd party types here, so we could maybe introduce a combined interface in core that would be used internally.

Realistically, we already do those things a lot, that's what you get with making the public interface more strict. I wouldn't call this a design flaw at all.

@xcfox
Copy link
Collaborator

xcfox commented Feb 14, 2026

I roughly looked at the current implementation. Currently, there are some places inside that actively use as operations to bypass type checks.

To be honest, I think for complex functions, it's sufficient to ensure that the function's parameters and return values have the correct types. The variables inside the function are usually straightforward, and too many type annotations will make the internal code more verbose.

That said, perhaps we can use some techniques, such as leaving groupBy, having, maxTimeMS in an internal interface InternalFindOptions, and we can define the publicly exposed FindOptions as:

export interface FindOptions extends Omit<InternalFindOptions, 'groupBy' | 'having' | 'maxTimeMS'...>
export interface SqlFindOptions extends Omit<InternalFindOptions, 'maxTimeMS'...>
export interface MongoFindOptions extends Omit<InternalFindOptions, 'groupBy' | 'having'...>

This way, we can ensure the precision of options for each driver, while also guaranteeing the internal type checks of MikroORM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants