On Jun 16, 2010, at 10:50 , Dan K. (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.”
