26 ms·

Nitpicking here, solnic didn't reimplement ActiveRecord (he did, but that's long ago) -- ROM implements the DataMapper pattern.

• vinceguidry 10y ago
  I can nitpick too! :) I never said he reimplemented active record, I said he reimplemented ActiveRecord. Though I suppose the better verb to use would have been 're-engineered'. Reimplementing seems to imply an algorithm or design pattern, where I meant to re-do the functionality.
  • spraak 10y ago
    >I never said he reimplemented active record, I said he reimplemented ActiveRecord You didn't yet you did? You've said the same thing twice here
    • vinceguidry 10y ago
      ActiveRecord is an implementation of the active record pattern. DataMapper is an implementation of the data mapper pattern. https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Active_record_pattern https://en.wikipedia.org/wiki/Active_record_pattern
      • lgierth 10y ago
        The ruby lib DataMapper is actually an implementation of the active record pattern too ;) That's one reason to why ROM exists.
• ssmoot 10y ago
  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_mapper/repository.rb#L72 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 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.