WTF. No concept of the N+1 problem.
> We’re still struggling with which database engine to use for the final deployment. I thought Hibernate was portable, but we have some native queries that use some MS SQL magic, and we’d actually like to go with MySQL in the production
WTF. Why are you developing against MS-SQL then?
> Sometimes we spend days looking for errors. It seems like we have to analyze Hibernate-generated SQL because we have no idea why it’s not working as expected and it’s producing unexpected results.
WTF. If you don't understand your ORM you won't understand the queries it generates.
> Can you help me understand how Hibernate cache works? I just don’t get it. There are some first/second level caches. What is this all about?
WTF. No concept of using transactions.
I've used ORMs longer than the term ORM existed. I've never once thought it as a replacement for SQL. It's a supplemental tool.
Huh? I feel like I'm missing something. Eager loading, done right, is how you avoid the N+1 problem.
In ActiveRecord, Customer.includes(:orders).where(customer_name: 'Fred') would execute, at most, two queries even if there are many Freds with many orders.
The only real ORMs I've used are ActiveRecord and a tiny bit of EntityFramework.
Is this kind of eager loading not common? Or did I misunderstand your remark?
This can be avoided with something like e.g. EntityFramework which is based on the IQueryable interface and expression trees. In EF it would be
var query = DbContext.Customers.Include( c => c.Orders).Where( c => c.customer_name == "Fred");
This isn't uncommon. Where I'm working now we're actually busy implementing our own transactions to solve performance issues :(
Even rarer, almost no one is aware of implicit transactions. Developers: Always use a transaction, if you aren't then you are using many more implicit transactions.