datamapper blues
in [Ruby]
|
Prev: check Fixnum
Next: Looking for some documentation.
From: Dave Howell on 16 Jun 2010 01:29 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.
From: Hassan Schroeder on 16 Jun 2010 11:11 On Wed, Jun 16, 2010 at 2:45 AM, Richard Conroy <richard.conroy(a)gmail.com> wrote: > There is just not enough good information that helps people break through > this glass ceiling. > > None of these solutions are code/api specific. Its just advanced > documentation. There is precious little out there > in terms of blogs, articles, editorial or books that documents real world > situations, and... ...and you're going to help fix that? You'll post the URL of your tutorial/article/blog post here? :-) Thanks! -- Hassan Schroeder ------------------------ hassan.schroeder(a)gmail.com twitter: @hassan
From: Dan Kubb (dkubb) on 16 Jun 2010 13:46 > 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. > 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. Sequel is a fine ORM, and is very well designed. If it meets your needs, then I think that's great. It's probably better if you want to work at a layer closer to the database, and work with SQL more directly. You're also correct that ActiveRecord probably won't support arbitrary schemas. However DataMapper should be able to map to most existing schemas, since the table name and column names can be overridden as needed. It also provides a default naming convention layer, but you can even override that and provide your own code. > 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. It probably isn't very common since ActiveRecord is probably used by 10x more people than DataMapper or 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. You can even specify different names for the columns in ruby as in the DB, eg: property :table_id, Serial, :field => 'tableID' If this wasn't clear from the DataMapper documentation, that's our failing not yours. We need to start documenting how the mapping works better, and show people how most schemas can be handled, and you can use specific naming conventions in your ruby code and schema while maintaining loose coupling between them. -- Dan
From: Martin DeMello on 16 Jun 2010 14:57 On Wed, Jun 16, 2010 at 11:20 PM, Dan Kubb (dkubb) <dan.kubb(a)gmail.com> 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. Actually my main problem isn't the legacy schema, it's datamapper's behaviour when something doesn't save. It makes debugging during development really hard unless I put a begin/rescue or if/then block around every db write. martin
From: Dave Howell on 16 Jun 2010 16:24
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." |