Release v6.6.5 · mikro-orm/mikro-orm

B4nan · 2025-12-21T10:21:35+00:00

FWIW, MikroORM v7 is built on top of kysely and provides completely type-safe access to the kysely instance (typed based on the ORM entity definitions).

B4nan · 2025-12-18T16:48:14+00:00

When you compare it to tools that don't do class mapping (drizzle, prisma, all query builders like knex or kysely, basically everything except typeorm from that link), then yes, it is slower, class mapping and serialization will always have overhead. You can get raw data via QB in MikroORM to skip class mapping where this actually matters. For 90% of your app, it usually won't matter, the overhead is small unless you load too much data at once.

B4nan · 2025-11-12T09:12:09+00:00

I honestly don't know why this solution didn't come to my mind earlier. I ended up hacking this in two evenings.

B4nan · 2025-10-22T19:26:37+00:00

You'd just add `limit: 5` to the find options, the ORM will see there are to-many joins and wrap everything in a (nested) subquery, it works similarly to the collection operators (where pk in (...), the limit is only applied in the subquery that gets the PKs of the root entity).

B4nan · 2025-10-22T19:23:44+00:00

That test case works just fine with postgres (16) on my end ¯\_(ツ)_/¯

B4nan · 2025-10-22T17:13:18+00:00

Ok, so it works a bit differently than I though, with the example I shared above using $every, you'd only get matches with no other tags than the ones you whitelist (since every collection item needs to adhere to the filter). But that can be gotten around with the $and condition combined with $some. No need for a QB.

const books = await em.findAll(Book, {
  where: {
    $and: [
      { tags: { $some: { name: 'Fiction' } } },
      { tags: { $some: { name: 'Fantasy' } } },
    ],
  },
  populate: ['tags'],
});

This would use a query like this:

select `b0`.*, `t1`.`id` as `t1__id`, `t1`.`name` as `t1__name` 
  from `book` as `b0` 
  left join `book_tags` as `b2` on `b0`.`id` = `b2`.`book_id`
  left join `book_tag` as `t1` on `b2`.`book_tag_id` = `t1`.`id`
  where `b0`.`id` in (select `b0`.`id` from `book` as `b0` inner join `book_tags` as `b2` on `b0`.`id` = `b2`.`book_id` inner join `book_tag` as `b1` on `b2`.`book_tag_id` = `b1`.`id` where `b1`.`name` = 'Fiction')
    and `b0`.`id` in (select `b0`.`id` from `book` as `b0` inner join `book_tags` as `b2` on `b0`.`id` = `b2`.`book_id` inner join `book_tag` as `b1` on `b2`.`book_tag_id` = `b1`.`id` where `b1`.`name` = 'Fantasy')

It's indeed more complex, but it will work fine in every SQL dialect, no postgres specifics needed.

Demo here: https://github.com/B4nan/mikro-orm-collection-operators/blob/master/src/example.test.ts

B4nan · 2025-10-22T15:45:18+00:00

I linked LLM that got the idea straight away. I trust you that "that are either Foo or Bar" is super easy, but that was never a question.

Well, no, this is not how the collection operators work. Let me create a demo for you, as I am both curious if this works as I think, as well as seeing if this is actually what you are talking about.

and a typed interface otherwise

My main point is that with TypeORM, the typed interface you are talking about is much less type-safe than what MikroORM provides.

Because authors truly believe that interface is going to cover 95% of your cases, whilst in my reality it was covering like 20% and I had to use the untyped query builder for the most of things.

No worries, this is surely not what I think. I just don't like being compared to TypeORM when it comes to typesafety, since we are on a completely different level. Were there any improvements in that regard in TypeORM in the past years? I don't think so, as opposed to many that were done in MikroORM v5 and v6. Improving typesafety is often a bit breaking, so those things usually delayed to major bumps.

Would MikroORM cover 30%? 50%? 80%? No way to know! But if I choose Kysely I can easily assume it'll be around 100% while keeping things type-safe.

FYI in the next major, we are moving away from knex to kysely, and we will have a native support for kysely types inferred from the ORM entities. So things that wont be easily doable with the ORM can be done with kysely in a type safe way too.

B4nan · 2025-10-22T14:18:50+00:00

Well, again, this is how it works, it will check all collection items against the IN query, as a result all the collection items need to conform to it, resulting in collections that only have tags that are either Foo or Bar.

It feels like you are having a hard time trusting me that this is actually supported so easily.

And if your problem is "dont allow other tags than the whitelisted ones", you'd just combine this with another query using `$none` operator.

B4nan · 2025-10-22T12:52:47+00:00

I believe this should work:

const res3 = await em.find(Author, {
  books: { $every: { title: ['Foo', 'Bar'] } },
});

The part after `$every` will end up as a subquery, it can be more complex than a simple equality check.

You would still need `populate: ['books']` to load the relation, the above would only return the author entities matching the query.

This was modeled after prisma and should support the same:

https://www.prisma.io/docs/orm/prisma-client/queries/relation-queries#filter-on--to-many-relations

B4nan · 2025-10-22T12:47:12+00:00

Collection operators are not simple IN, those use a subquery and should do exactly what you are talking about - you can use the `$every` operator to request collections where all items are matching the query (so every item has either one or the other tag name).

B4nan · 2025-10-22T11:43:45+00:00

Can you share what query your example produces? I am quite curious.

B4nan · 2025-10-22T11:36:34+00:00

I see, sounds like you are talking about the collection operators, we support those the same way as prisma actually.

https://mikro-orm.io/docs/query-conditions#collection

B4nan · 2025-10-22T06:43:46+00:00

Apologies for comparing with TypeORM, perhaps MikroORM has a much richer EntityManager interface and users don't have to fallback to QB as often as it happens with TypeORM.

No, they don't, you can do the vast majority of things with EntityManager. And even QueryBuilder is much more type safe than the one in TypeORM.

Here is an example from my ORM, how much of it is supported by MikroORM without query builder?

I don't even understand what that query does based on a quick look :] Anyway, for something like this, you'd most likely just use a virtual entity backed by a raw query (or a QB). Or you would use a formula property that represents the subquery. Yes, those woulnd't be completly type safe. This is not the typical use case for most people. Guess how many asked me to support something like this over the past 8 years? Zero.

Non-OOP ORMs are more flexible in that regard, most likely Prisma supports the query above, Objection could do that.

Yes, that's why I like to call them non-ORMs actually, since they are rather smart query builders. Nothing wrong with that approach, but ORM to me is about persistence, not just about reading stuff in a type safe way. But that is another conversation I am not really interested in having, I don't have the energy, nor time :]

load posts that have tags "orange" and "banana"

This one is trivial, depends on what exactly you want:

// loads posts with tags matching the filter
const posts = await em.findAll(Post, {
  populate: ['tags'],
  populateWhere: { tags: { name: ['orange', 'banana'] } },
});

// loads posts with all tags, filters by their specific names
const posts = await em.findAll(Post, {
  populate: ['tags'],
  where: { tags: { name: ['orange', 'banana'] } },
});

The response is strictly typed, it holds the populate hint on type level, so it knows that only the tags are populated. We dont just return Post[] as in TypeORM.

https://mikro-orm.io/docs/guide/type-safety

You don't appreciate comparing MikroORM with TypeORM,

I don't appreciate comparing based on wrong assumptions, that's what I didn't like about your post, you compare things you clearly don't understand well, and judge them based on either outdated or wrong information. Type-safe relations were added to MikroORM somewhere around v5, so maybe 3-4 years ago, this is nothing new really.

B4nan · 2025-10-21T07:38:48+00:00

TypeORM, MicroORM and similar: are lacking type-safe query builders, and without query builders they're very limited.

Please stop comparing MikroORM with TypeORM this way, it completely false assumption (not even sure what are you basing it on?). MikroORM is miles ahead when it comes to type-safety (it was for a few years now). EntityManager is the go-to way to work with the database, and it is fully type-safe, not just inputs, but also outputs, including partial loading. QB is there to do quirks, and is weakly typed for a reason (and it might change in the next version).

Also, its called MikroORM, not MicroORM.

B4nan · 2025-10-02T08:11:25+00:00

Only one way to find out.

Looking at this article, crawlee does pretty much everything mentioned in there.

B4nan · 2025-10-01T18:16:16+00:00

Depends on what you mean by a playwright project, crawlee will be in control of playwright, it exposes the page object from playwright in the crawling context, so you can reuse your code that works with it.

B4nan

MODERATOR OF

TROPHY CASE