Comments on: DNR, generics, and O/R mapping http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/ Tue, 18 Aug 2009 22:20:45 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-134 Anonymous Mon, 06 Dec 2004 13:16:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-134 I agree that choosing not to load a few int or varchar fields is pointless. I just thought that the the idea of using attributes was interesting, whenever I hear about people using attributes it usually relates to logging or security, so to hear about another application of attributes caught my attention. I'm by no means an expert on o/r mapping, I didn't even know it was called that until hearing the show! Thanks for the comments! I agree that choosing not to load a few int or varchar fields is pointless. I just thought that the the idea of using attributes was interesting, whenever I hear about people using attributes it usually relates to logging or security, so to hear about another application of attributes caught my attention. I’m by no means an expert on o/r mapping, I didn’t even know it was called that until hearing the show! Thanks for the comments!

]]> By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-133 Anonymous Mon, 06 Dec 2004 06:44:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-133 I am very sorry to say, but the proposal is utterly stupid in 99% of the occasions. Basically the transfertime for object retrieval is much lower than the round trip to the database, and a smart in memory caching scheme may allow only to retrieve the pk and the lock fields, then reuse the object if it is unchanged. MUCH better. <br> <br>The one time when this is not the case is basically when the table is getting larger than let's say 8k (page size in SQL Server). Once you store large documents or eve nbinary data (images), lazy loading does start to really make a show out of this. <br> <br>And this coming from the maintaine of one of the most powerfull O/R mappers for .NET on the market. I am totally in agreement with Frans here. Simply makes no difference, makes the object slower. It also kills caching layers and produces way more database round trips. I am very sorry to say, but the proposal is utterly stupid in 99% of the occasions. Basically the transfertime for object retrieval is much lower than the round trip to the database, and a smart in memory caching scheme may allow only to retrieve the pk and the lock fields, then reuse the object if it is unchanged. MUCH better.

The one time when this is not the case is basically when the table is getting larger than let’s say 8k (page size in SQL Server). Once you store large documents or eve nbinary data (images), lazy loading does start to really make a show out of this.

And this coming from the maintaine of one of the most powerfull O/R mappers for .NET on the market. I am totally in agreement with Frans here. Simply makes no difference, makes the object slower. It also kills caching layers and produces way more database round trips.

]]> By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-132 Anonymous Sun, 05 Dec 2004 07:14:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-132 I checked out your LLBLGen Pro demo, I think its really cool, I like the how you attach an event to every field. Judging from your previous comment I would expect that your product does not use lazy loading, is this correct? I checked out your LLBLGen Pro demo, I think its really cool, I like the how you attach an event to every field. Judging from your previous comment I would expect that your product does not use lazy loading, is this correct?

]]> By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-131 Anonymous Sun, 05 Dec 2004 05:33:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-131 The only way I can think of is that you specify a set of fields for a given type T you're fetching objects of, which have to be excluded for this particular fetch. The engine then has to offer a way to fetch these fields 'when necessary', later on, either by a lazy loading mechanism or by a manual fetch. The only way I can think of is that you specify a set of fields for a given type T you’re fetching objects of, which have to be excluded for this particular fetch. The engine then has to offer a way to fetch these fields ‘when necessary’, later on, either by a lazy loading mechanism or by a manual fetch.

]]> By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-130 Anonymous Sun, 05 Dec 2004 04:32:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-130 You make an excellent point about the static nature of the attributes, and the inability to change them to fit different scenarios, I hadn't considered that. You are right about needing to pass information in order to load the proper fields, I'm just wondering if there is an elegant way to accomplish this without having to write anything that is similar to SQL code, I would rather do it in an OO fashion. You make an excellent point about the static nature of the attributes, and the inability to change them to fit different scenarios, I hadn’t considered that. You are right about needing to pass information in order to load the proper fields, I’m just wondering if there is an elegant way to accomplish this without having to write anything that is similar to SQL code, I would rather do it in an OO fashion.

]]> By: Anonymous http://benreichelt.net/blog/2004/12/04/dnr-generics-and-or-mapping/comment-page-1/#comment-129 Anonymous Sat, 04 Dec 2004 20:55:00 +0000 http://s194721765.onlinehome.us/blog/2004/12/04/dnr-generics-and-or-mapping/#comment-129 ANY static defined lazy loading scheme is stupid. The reason for that is that it can't scale to situations in which you want to change the statically defined settings. <br> <br>So instead of using statically defined lazy loading (with attributes, which is also cumbersome to implement, i.e. what if your system has 500 entities?), implement a lazy loading scheme which allows the developer (i.e. the user of the data at that point in time) to define what scheme to use as only that developer can tell what's best for that particular situation. <br> <br>So the obvious choice is passing a construct to the fetch logic which describes which fields to load. Obviously, the system has to keep track of which fields are already loaded. (but perhaps the developer wants to re-load the field at every access, also a reason not to use statically defined lazy loading). <br> <br>Lazy loading of blobs is the only real world scenario which will increase performance. However, in general, these scenario's are pretty rare. Lazy loading has a disadvantage: your tier in which the lazy loading is triggered has to have a context which is connected to a database. Especially with the larger applications, this is not what you want in for example a GUI tier. <br> <br>I can only conclude that the show you've listened to contained people who heared about O/R mapping but clearly don't understand what it really is nor what it means for enterprise applications to use O/R mapping. ANY static defined lazy loading scheme is stupid. The reason for that is that it can’t scale to situations in which you want to change the statically defined settings.

So instead of using statically defined lazy loading (with attributes, which is also cumbersome to implement, i.e. what if your system has 500 entities?), implement a lazy loading scheme which allows the developer (i.e. the user of the data at that point in time) to define what scheme to use as only that developer can tell what’s best for that particular situation.

So the obvious choice is passing a construct to the fetch logic which describes which fields to load. Obviously, the system has to keep track of which fields are already loaded. (but perhaps the developer wants to re-load the field at every access, also a reason not to use statically defined lazy loading).

Lazy loading of blobs is the only real world scenario which will increase performance. However, in general, these scenario’s are pretty rare. Lazy loading has a disadvantage: your tier in which the lazy loading is triggered has to have a context which is connected to a database. Especially with the larger applications, this is not what you want in for example a GUI tier.

I can only conclude that the show you’ve listened to contained people who heared about O/R mapping but clearly don’t understand what it really is nor what it means for enterprise applications to use O/R mapping.

]]>