Re: datamapper blues

On Jun 16, 2010, at 10:50 , Dan Kubb (dkubb) wrote:

>> I've ranted about this elsewhere, so I'll keep this short, but I urge you to not be misled by the word "legacy."
> 
> This thread was started by someone having problems using an ORM with a
> legacy schema, so that's what we've been discussing mostly. However,
> this problem can be more generally classified as an issue with
> controlling the mapping between an existing schema and ruby classes.

Exactly. I just wanted to encourage you (and everybody working with ORMs) to consider the issue more broadly. 


> However DataMapper should be able to map to most existing
> schemas, since the table name and column names can be overridden as
> needed. 

I wouldn't be at all surprised. In the end, the reason I landed on Sequel instead of Datamapper is because I couldn't figure out either one from the documentation, so I asked on this list for a recommendation for an ORM based on my intended use, and four people suggested Sequel. 

>> 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.
> 
> DataMapper makes no assumptions about what should be the PK or not. It
> trusts whatever you tell it about the mapping/types and acts
> accordingly. 

> If this wasn't clear from the DataMapper documentation, that's our
> failing not yours.

I'm not sure I got quite that far, but that wasn't actually the point I was trying to make. Sequel also will happily use whatever PK I tell it. What surprised me was that I *would* have to tell it. 

In PostgreSQL (and yes, I know, this is almost certainly DB-engine specific):
	SELECT column_name, position_in_unique_constraint
	FROM information_schema.key_column_usage join information_schema.table_constraints using (constraint_name)
	WHERE  constraint_type='PRIMARY KEY' AND table_constraints.table_name = 'name_of_table'
	ORDER BY position_in_unique_constraint
will tell me which columns (if any) make up the primary key for a particular table. 

As somebody hitting ORMs without a Rails background, what I *really* needed to get me up and running was a good example of what my object maps were supposed to look like. This is where ActiveRecord completely melted down on me. It took me nearly an hour to figure out how to ask it to construct an object set from an existing schema, and then when I ran the generator, it tripped over a non-standard type and failed to construct most of the objects. 

Sequel did better; it made an object for every table. However, it didn't find any of the relationships. It did the easy part, but left the hard part for me. (OK, not THAT hard . . .)

Now, I realize that there is a point beyond which this sort of thing stops being reasonable. Identifying many-to-many relationships would be pretty tricky to do in the general case. And as I've gotten deeper into all of this, I've come to understand why nobody has a tool like that. Yet. 

Anyway, since you expressed interest in improving Datamapper's usefulness to people working with pre-built schemas, I figured I'd chip in since it's all quite fresh in my mind. With most of the ORMs I looked at, I often found people mentioning in passing "of course, you can [define alternative primary keys, use non-pk columns for one-to-many relationships, et cetera]" but not then providing an example of HOW. I think in many cases, the information is actually in the documentation, somewhere, but not in a form that's recognizable or accessible to somebody unfamiliar with the system. My experience with Rails would probably have been very very different if somebody had created a tutorial that was something like "Now, the scaffolding helpers are pretty cool, but here is how you can build your mapping objects by hand. From scratch. With all the bells and whistles."