Re: datamapper blues

On Tue, Jun 15, 2010 at 9:00 PM, Dan Kubb <[e-mail]/> 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