Every non-trivial project that uses an ORM will, at one point, fetch the whole database.
Either by someone accidentally creating mappings that do it without noticing or someone not understanding that there's a whole-ass database in there and they just fetch everything local and filter with a for-loop.
I have been coding on Java since v1 and wrote basic ORMs before Hibernate was a thing (yes, in EJB world). There were pretty big and complex projects in fintech and healthcare, but I have never encountered the situation you describe. Maybe I was lucky, but logically you cannot say “every non-trivial project”.
Some years ago Entity Framework followed navigational properties (foreign keys) by default, which quickly escalates. The scenario could be a user table referencing a organisation table, so that when quering for an org, you’d get every user.
I dont think EF ever did that. However, if you used automatic lazy loading and you somehow inadvertently referenced the collection, then yes, it would lazy load the related entities.
This must be a mistake that you do once as a junior and then never repeat. When you declare a field with collection, would not it be natural to ask how it works?
Definitely! The problem though, is that this issue creeps up on you over time, and maybe only i production, because the performance is directly correlated to the amount of data in the database.
But I guess issues like these are what transition you from junior developer into whatever comes next.
Either by someone accidentally creating mappings that do it without noticing or someone not understanding that there's a whole-ass database in there and they just fetch everything local and filter with a for-loop.