ActiveRecord != DataMapper
January 16th, 2008
As a follow-up to Rails || Merb, I’m going to highlight some of the differences between ActiveRecord (AR) and Datamapper. Merb is ORM agnostic so you can still use AR if you want to, but I thought I might as well try DataMapper out.
Datamapper (DM) isn’t really production ready at the moment as migrations are destructive, but hopefully that’ll change in the next few months.
The first thing you’ll notice is that in DM the properties of the database are in your model, where in AR they are in a migration.
Take a look at this example DM model:class Post < DataMapper::Base
property :title, :string
property :textile, :text
property :created_at, :datetime
end
rake dm:db:automigrate || DataMapper::Base.auto_migrate!
With AR this would be in a migration, not to dissimilar to this:
class CreatePosts < ActiveRecord::Migration
def self.up
create_table :posts do |t|
t.string :title
t.text :textile
t.timestamps
end
end
def self.down
drop_table :posts
end
end
rake db:migrate
I should point out that just like AR the created_at field is automatically filled in by DataMapper.
DataMapper has a few ActiveRecord impersonations such as the follow methods: [], all, count, create, create!, delete_all, each, find, find_by_sql, find_or_create, first, get, truncate!, destroy!, included, reload, reload!, save
Here is a list of some syntax comparisons:
| The AR way | The DM way |
| User.find(:all) | User.all |
| User.find(10) | User[ 10 ] |
| @user.update_attributes(:name => ‘Matt’) | @user.update_attributes(:name => ‘Matt’) |
| User.find(:all, :conditions => :sex = ‘Female, :age > 21) | User.all(:sex => ‘Female’, :age.gt =>21) |
| User.find(:all, :conditions => [“id IN (?)”, [1,3,37]] | User.all(:id.in => [1,3,37]) |
| has_many :through | not implemented yet |
Something you might want to watch out for, covered by Jon is that DM will only persist changes that it manages, so if you’re using virtual attributes you’ll need to mark the model as dirty. Also there are currently bugs in finding with conditions on associations and count.
8 Responses to “ActiveRecord != DataMapper”
Sorry, comments are closed for this article.






DM’s got classic migrations now (at least they’re there in trunk)...
Jonathan, how good are Datamapper’s migrations beyond the simple table creation? I mean like updating some counter cache I add at a later point?
One thing I don’t understand about DataMapper is its usage of the terms property and attribute. When is something a property and when is it an attribute? This seems a little confusing.
@Jon, true there are migrations in trunk but I presume they are still destructive so what benefit over auto_migrate do they provide (other than a history, which would be in your version control system)?
@Carl, I believe that a property defines an attribute, its type and the default value.
I was actually quite impressed with DataMapper. The documentation made sense, and the overview on the website was quite informative.
As for ActiveRecord, well i’ve had my ups and downs with that. The distinction between Model and the Migration was a bit annoying.
For example, when manipulating my schema via the Migration, i often had the associated Model break. Which is great if you are on the previous version, but the more versions behind you are, the more things can go wrong when upgrading – especially if you rely on methods in your models, or you decide to use another database and find that what worked in MySQL in version 1 totally barfs up with SQLite.
IMO, DataMapper is doing the right thing by sticking the schema in along with the model. That way i can think of versioning the Model as a whole.
@carl – Properties are still attributes of a DM managed class however the difference is that DM manages their persistence.
@Matt + @thomas – I’m pretty sure the classic migrations aren’t destructive (well they can be if so wished, or I might have misunderstood:)). A DM migration is just a class that inherits DataMapper::Migration in a similar way to Rails migrations. You can manipulate and change your schema/data anyway you wish in the ‘up’ and ‘down’ methods just like you can in Rails. Is this what you mean?
Cheers my dears
Jonathan
@Matt & @Jonathan – Thanks for the explanation! DataMapper looks really cool and I’ll try it out next time I start a merb app.
Hey, nice comparison, I noticed one issue, this:
DataMapper::Base.auto_migrate!
has been changed into this:
DataMapper::Persistence.auto_migrate!
Cheers!