SSssmoot·May 23, 2016
The idea that DM wasn't a DataMapper is misguided. Check out: https://github.com/datamapper/dm-core/blob/0.9.0.1/lib/data_...
The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class.
Turned out this was a bad idea if your primary motivation is performance.
The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick.
The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it
Read the rest
was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)).
The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem.
The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.