• The first ORM I worked with was from the early 90s. It was a non public implementation, and I was unaware of any public ones at the time (the internet was young). Just several years ago, public ones started to come to my attention and they were essentially no more advanced as the one I used back then.

    Newer implementations I haven't worked with since, but partial loading of object properties sounds like a very dangerous thing to me. A lot can go wrong with data/state consistency and as such I am far from convinced that it should be called "progress". I can see it work nicely when the property partitioning of a entity matches the horizontal partitioning in the database. Then of course it is hardly mapping, but just catching up to the real state in the database and cutting unneeded load overhead when possible (for large data types for example that are not always needed).

    So I do see ORM's have a place, for those low hanging fruits where there aren't too many hard differences between the relational model and the object model as used by the programmer. But as soon as a application model gets more complicated it is just asking for trouble. In trying to paper over the mismatch you get hard to maintain and optimize code, with a generated base or not, which hardly matters at that point.