From: Dave Howell <groups.2009a@...>
Date: 2010-06-16T14:29:41+09:00
Subject: Re: datamapper blues


On Jun 15, 2010, at 13:00 , Dan Kubb wrote:

> Richard,
> 
>> In practice I have found it a challenge to make DataMapper conform to legacy schema, and error feedback was limited.
> 
> This is great feedback to have, and precisely the kind of information I need in order to improve DataMapper.
> 
> Now that DM 1.0 is out, and the API is stable, DM is shifting the focus a bit. One of the primary areas I want to improve is legacy schema mapping, since I think that's a bigger issue than we'd like to admit in the ruby world.
> 
> Most projects are not beautiful "green field" apps. Almost every company has legacy systems that sit in the corner, and programmers dread having to work on them. 

I've ranted about this elsewhere, so I'll keep this short, but I urge you to not be misled by the word "legacy." I've just started working on a brand new database project for a client, and I ended up using Sequel instead of Datamapper or ActiveRecord because it looked like it would be much easier to support the full PostgreSQL feature set with Sequel. (I  I did rename my primary keys from tableID to table_id because Sequel would auto-find them, but I did NOT rename my linking tables. I'll still be writing a lot of raw SQL code when working on this project, and I expect my ORM to deal with what I give it, not vice versa. (And I cannot imagine *ever* giving my Ruby code the ability to modify the database schema.) 

While it's very clear that, at least among Ruby fans, my 'database first' approach isn't very common, I do know that I'm not the only person who designs this way. 

Anyway, 'read only' access to a database schema is not synonymous with supporting legacy systems. I was really really surprised when I first realized that none of the major ORMs I looked at were clever enough to figure out that, if the DB engine calls a column a Primary Key, then, um, it's the Primary Key. I almost wrote some code for Sequel to build out its p-key and f-key relationsihps from the database, but realized it would take me a lot longer to write that code than to just reconstruct the relationships by hand on the Ruby side, especially since I'm just learning how it works.