On Tue, Jun 15, 2010 at 9:00 PM, Dan Kubb <[email protected]/> wrote: <crossposted from Ruby-Talk>
> 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. > > As the maintainer of DataMapper I want to help solve this problem, or at > least make it less painful. Even if we partially solve it and someone else > extends that work I'm cool with that too. At the very least I am going to > give it a good try. There are *so* many developers who would love to use > Ruby, but aren't able to because the more "mainstream" tools don't work for > them. > > Richard, I would love to hear more about the problems you ran into using DM > with a legacy DB, whether it's here or on the datamapper mailing list. > My biggest problem was with associations. I had to model a SQL schema in DataMapper that had some relationships that didn't map conveniently to the has n model. In fairness the schema was a bit on the complex side and I had bitten off more than I could chew: around 16 tables all networked by associations. For me what would have helped most was a directory of SQL schema and how you model it in DataMapper. There has already been a thread here on ruby-talk bemoaning the state of documentation in Ruby projects. I found the standard of DM's documentation to be pretty good as Ruby projects go, but it needs to be covering these edge cases. I would consider DM to be one of the top Ruby libraries, and it needs the depth of documentation that we are used to with its peers. I think that now is a good time for a DataMapper book, for instance. I think the biggest problem is that people can rave over DM in the trivial case, and docs, blogs etc. are very good in this space. Where people get really stuck is when they get more ambitious in their SQL/schema use: applying it to legacy schemas or large schemas which have been aggressively normalized. One area that I didn't like, was that it is trivial to use DM in a ruby way, that makes for very poor DB usage. For instance, I could kill DB performance very trivially. Good idiomatic ruby code, when applied to DM models, does not make for good idiomatic database use. Note these were my experiences while learning DM in a challenging environment, YMMV. But I suspect that these kind of growing pains can be a turnoff - as they happen after you have drunk the kool-aid and been sold on DM for trivial projects. People may question the value of DM as their schema grow in complexity. 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 I think thats an area that DataMapper should concentrate on. I don't have any criticisms of the API itself. regards, Richard -- http://richardconroy.blogspot.com -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
