4 ms·

This is not a problem with all ORMs. This is caused by lazy loading the related data when it is accessed, which is not how all ORMs work. If your ORM requires y

This is not a problem with all ORMs. This is caused by lazy loading the related data when it is accessed, which is not how all ORMs work. If your ORM requires you to define the included related data explicitly, you won't have this particular problem.

Arch-TK 4y ago
And an ORM which eagerly loads all related data before it is accessed will have a different but related problem. I'm actually not aware of any ORM which tries to do more than trivial guessing of when data needs to be eagerly loaded. There is no easy way of solving this problem within an ORM without either causing a different problem or without leaking the abstraction a lot and requiring lots of additional complexity to annotate what you want the ORM to actually do.
- Lapsa 4y ago
  real fun begins when random Cartesian products shits up all your RAM
- fabian2k 4y ago
  In EF Core for example you have to specify which relations to include, either using ".Include()" or transforming the entire query with a "Select()". In the latter case this works pretty much automatically as long as you stay within the kinds of expressions EF Core can translate to SQL. There is a different performance problem lurking with this design though. You have to decide whether to tell EF Core to do a query per relation or everything in one query. The single query is very efficient for many simple cases and ensures consistency, but it can fail spectacularly if you have a very large number of relations. This is a pretty significant footgun, but if you really don't want to be bothered with this you can just always use split queries. ORMs can't really abstract over all performance considerations. They are convenient, but they can't fully hide what the database is doing under the hood.
  - deleted 4y ago
    [deleted]
- imtringued 4y ago
  You just specify which relations you want to load in your query. It is that simple. There is no gotcha here.
  - guggle 4y ago
    I don't know why this comment is downvoted. That's how Django ORM works too (select_related)
    - Izkata 4y ago
      The abstraction leakage in Django is to know whether you should use "select_related" or "prefetch_related".

Arch-TK 4y ago

And an ORM which eagerly loads all related data before it is accessed will have a different but related problem. I'm actually not aware of any ORM which tries to do more than trivial guessing of when data needs to be eagerly loaded. There is no easy way of solving this problem within an ORM without either causing a different problem or without leaking the abstraction a lot and requiring lots of additional complexity to annotate what you want the ORM to actually do.

Lapsa 4y ago
real fun begins when random Cartesian products shits up all your RAM
fabian2k 4y ago
In EF Core for example you have to specify which relations to include, either using ".Include()" or transforming the entire query with a "Select()". In the latter case this works pretty much automatically as long as you stay within the kinds of expressions EF Core can translate to SQL. There is a different performance problem lurking with this design though. You have to decide whether to tell EF Core to do a query per relation or everything in one query. The single query is very efficient for many simple cases and ensures consistency, but it can fail spectacularly if you have a very large number of relations. This is a pretty significant footgun, but if you really don't want to be bothered with this you can just always use split queries. ORMs can't really abstract over all performance considerations. They are convenient, but they can't fully hide what the database is doing under the hood.
- deleted 4y ago
  [deleted]
imtringued 4y ago
You just specify which relations you want to load in your query. It is that simple. There is no gotcha here.
- guggle 4y ago
  I don't know why this comment is downvoted. That's how Django ORM works too (select_related)
  - Izkata 4y ago
    The abstraction leakage in Django is to know whether you should use "select_related" or "prefetch_related".