http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Lazy field initialization is indeed key to many advanced optimization scenarios, such as: 1) Loading only the fields you´re going to need for a use case 2) Avoiding loading fields twice 3) Enable lazy loading of large fields such as blobs Projections are (unless they are updatable) only really useful for read only use cases. http://ayende.com/2739/optimizing-nhibernate#comment9http://ayende.com/2739/optimizing-nhibernate#comment9Sun, 26 Aug 2007 20:18:40 GMTColin, Usually, that is not meaningful. It only comes into play in rare occasions where you load several thousands of entities. http://ayende.com/2739/optimizing-nhibernate#comment8http://ayende.com/2739/optimizing-nhibernate#comment8Sun, 26 Aug 2007 17:57:45 GMT@Ayende - On the partial object queries part, do you know whether the fact that these objects don't end up in the session causes a noticable speed improvement with NHibernate? http://ayende.com/2739/optimizing-nhibernate#comment7http://ayende.com/2739/optimizing-nhibernate#comment7Sun, 26 Aug 2007 17:33:29 GMTIf you read my reply I try to clarify that I'm not at all advocating the use of Lazy field (or even collection) initialization. I think it's a smell. That doesn't mean it shouldn't be there to protect the developer and to enable more advanced scenarios, but it should set off a red light when it's used, or with adaptive fetching strategies, the next time the query was made it would be included. But yes, you're right about how I want projections to work, but it doesn't have anything to do with excluding large fields. It has everything to do with excluding fields I'm not going to use so that I can actually take advantage of indexes that cover those fields (an index on username that includes email for example) and cut down on bandwidth, hydration overhead and flush overhead while not introducing new anemic single use objects. http://ayende.com/2739/optimizing-nhibernate#comment6http://ayende.com/2739/optimizing-nhibernate#comment6Sun, 26 Aug 2007 15:48:22 GMTLazy field initialization is pretty slow in general, so it's a perfect example of a feature requested by someone who has no real clue how an o/r mapper works. Sure, if you just want to fetch 1 or 2 field from a single entity, it might be more optimal, but then again, you can also use a projection. "select new UserSummaryDetails(u.Username, u.Email) from User u" I think he wants: select new User(u.Username, u.Email) from User u so he can exclude fields for fetching, e.g. an Order entity which has a blob field with an offer .doc, an employee entity which has a photo field etc. Non ansi joins have some problems with some left/right join setups, where they lead to different results than you'd expect. Any o/r mapper should offer the ability to specify the 'on' clause for a join as it otherwise could lead to blind spots in what the o/r mapper could do so the user (the developer) is then forced to bypass the o/r mapper core which is always a pain. http://ayende.com/2739/optimizing-nhibernate#comment5http://ayende.com/2739/optimizing-nhibernate#comment5Sun, 26 Aug 2007 09:32:04 GMTJust for clarity (SQL Server): ANSI joins and where clause joins differ when you add more clauses to the join than just the A.key =B.key clause for outer joins. E.g. "left outer join B on A.key=B.key and B.type = 1" is not the same as adding these clauses to the where statement, as the latter removes all rows from the result set that does not have B.type = 1, while the former just return NULL for all columns from B for the rows in the result set. http://ayende.com/2739/optimizing-nhibernate#comment4http://ayende.com/2739/optimizing-nhibernate#comment4Sun, 26 Aug 2007 09:07:17 GMTHere's my reply: http://blog.eleutian.com/2007/08/26/OptimizingNHibernatePt2.aspx As an aside, we just had a horrendous issue with having a Photo blob in our user table. Any time we loaded several users, the flush would take a good 5 seconds as it compared every byte in every photo. Eek. We've been wanting to move photos to a separate table, and we're doing that now. http://ayende.com/2739/optimizing-nhibernate#comment3http://ayende.com/2739/optimizing-nhibernate#comment3Sun, 26 Aug 2007 00:54:23 GMTI'd have to have a really good reason to do it, but you could always bypass NHibernate for iBatis.Net to regain full control over the SQL for optimization or trickery. I think it's more repetitive work to use iBatis than Hibernate, but you get full control. Of course it's setting you on a slippery slope to procedural, data-driven code hell. http://ayende.com/2739/optimizing-nhibernate#comment2http://ayende.com/2739/optimizing-nhibernate#comment2Sun, 26 Aug 2007 00:11:49 GMTRe: Lazy Field Initialization -- In your example, loading everything but the Photo BLOB, this could be done by creating a separate CustomerPhoto table+entity and setting it up as a one-to-one. This has a secondary benefit at the db layer in that you may want to put such data into a secondary filegroup. http://ayende.com/2739/optimizing-nhibernate#comment1http://ayende.com/2739/optimizing-nhibernate#comment1Sat, 25 Aug 2007 23:05:29 GMT