Hacker News new | comments | show | ask | jobs | submit login

> We’re always struggling with lazy/eager fetching problems. At one point, we decided to do everything eagerly, but it seems suboptimal, and besides, sometimes it’s not possible to access some fields because there is no session, or something like that. Is that normal?

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.




> WTF. No concept of the N+1 problem.

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?


The N+1 problem is caused by lazy loading. It's when you have an entity, e.g. Customer which has a property Orders with a foreign key relationship to Customer. The property is not materialized until it's accessed, causing an extra (N+1) query to be run.

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");
The value of query is an expression until it is iterated or converted to e.g. .ToList(); The expression is built using the relationships defined in the mapping which allows EF to use a proper SQL join, avoiding two queries and the N+1 problem.


If eager loading seems sub optimal then I'd guess that the have some kind of data access or repository layer on top of nhibernate. Say there are 10 places requesting customer but only 1 that needs orders, using includes would be sub optimal. Of course, it's really their architecture that's sub optimal, not hibernate.


> WTF. No concept of using transactions.

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.


>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. Yes, but 99% of the documentation points to Hibernate as a replacement tool (for Sql, the begin/commit/rollback, joins, etc.)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: