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."
>=20
> 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.=20


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

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.=20

>> 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.
>=20
> 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.=20

> 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.=20

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=3D'PRIMARY KEY' AND =
table_constraints.table_name =3D '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.=20

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.=20

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.=20

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. =
=46rom scratch. With all the bells and whistles."