Re: Looking for ORM for 'legacy' database.

On Jun 11, 2010, at 10:31 , Walton Hoops wrote:

> On 6/11/2010 2:36 AM, Dave Howell wrote:
>> On Jun 11, 2010, at 0:48 , Brian Candler wrote:
>>=20
>>=20
>>> Dave Howell wrote:
>>>=20
>>>> The piece I couldn't find was "How do I tell ActiveRecord to =
convert the=20
>>>> database's "UUID" type to a string, and vice versa?"
>>>>=20
>>> Ah, I've never come across a database with a "UUID" type. I'd =
imagine AR=20
>>> would treat unknown types as strings, but you'd need to try it.
>>>=20
>> I had to hook a special library into Postgres in order to get the =
UUID type. Everybody (including me) expects AR to treat it as a string, =
but in fact, it threw an error because the column was an unknown type. =
That's why I was trying to figure out how to *tell* it to treat it as a =
string.
>>=20
> Strange, my version of Postgre (8.4) comes with a UUID type.

8.3 did not; I had to get a special external library module and hook it =
in. 8.4 requires that it be compiled in with a special switch (&/or =
might also accept the external module, I'm not sure.) --with-ossd-uuid

> Anyway since this seems to be something we're going back and forth on

{sigh} We're not really going "back and forth" on this. I knew when I =
first posted my query about alternative ORMs that I would inevitably get =
a lot of people trying to solve my original problem, even though I tried =
to make it clear that whether or not ActiveRecord *could* work was NOT =
the issue for me.=20

The problem is the documentation. Not ActiveRecord. The documentation.=20=


When I first decided it was time to learn a new language a few years =
ago, I didn't decide to learn Ruby because it could do the most things. =
In fact, it was quite clear that Ruby would be quite a bit LESS capable =
than PHP, Perl, or Python. It was really new; there were a lot of =
libraries and whatnot that had not yet been ported. But it was also =
quite clear that it would do _most_ of what I wanted to do, and would =
probably soon expand to cover nearly everything I would want. More =
importantly, what it did was make doing what I wanted to do EASY. I was =
going to have to learn how to think about programming in a whole new way =
(well, not a *whole* new way, since AppleScript is also object-oriented =
in its own peculiar way) but once I had, things that were merely =
"possible" in PHP or Java or whatever would be *easy* in Ruby.=20

In the past couple of weeks, I have gotten 'stuck' on a problem about =
six times. One with Sequel, one with Rails/ActiveRecord, one with =
Ramaze, two with Haml, and I don't remember the last one. Of those six, =
the 'community' around them has managed to help me with three of them. =
The other three, nobody had a working solution for me. Now, three of six =
is pretty good, and people generally were willing to try to help me even =
if they couldn't solve my problem in the end. But advice from a mail =
list or chat room is a poor substitute for good documentation.=20

I also understand that the best way to get good documentation is to pay =
for it. Tango (now WiTango) comes with outstanding documentation, and =
costs $5000 per server to run. Documentation isn't all that much fun to =
create, so I don't expect the documentation for free &/or open source =
tools to be as good as for-profit commercial tools. Also, many of the =
Ruby tools I'm evaluating are very new, and haven't had time to accrete =
the documentation that they'll eventually have.=20

"Documentation" includes, of course, the myriad tutorials, blog entries, =
and mail list questions & answers archived on line. Rails, not =
surprisingly, has a LOT of 'documentation.' However, 99%+ of it takes =
migration for granted. I *know* that you don't HAVE to have migrations =
to use ActiveRecord; but I NEVER found anything that would actually tell =
me HOW to make a model from scratch by hand. I was *expected* to make =
the Ruby object, and migrate it TO the database.

A LOT of the online documentation was written by people who'd been using =
Rails for a while, and often was written FOR people who'd been using =
Rails for a while, so it takes a lot of Rails-behavior for granted. =
Perfectly reasonable, but it meant that a lot of the comments on mailing =
lists and stuff were fairly incomprehensible to me. It took me quite a =
while to figure out that I could ask Rails to build me my objects FROM =
my database. Since I hadn't been able to figure out what they should =
look like from scratch, this seemed like an excellent way to get =
started. I figured I'd have to modify/edit/improve them once that was =
done, but at least I'd have some place to start.=20

Unfortunately, that didn't work, because of the UUID problem. And for =
THAT, I could find *nothing* that seemed to offer a solution, even one I =
couldn't quite figure out. I rummaged through the source code, I Googled =
every possible variation I could think of, but nobody seems to have =
previously discussed how to add new types to ActiveRecord's =
understanding.=20

"This is a basic, fundamental ability." I said to myself. "If I cannot =
find the answer to THIS, what happens when I get to something that =
really is tricky?" Answer: I'm going to end up spending many hours =
trying to solve it myself, with just the source code (I hope) to go on.=20=


I don't care if it's *possible* to make Rails or ActiveRecord work =
without migrations, or correctly and comprehensively support Postgres's =
advanced data types (Arrays, IP Addresses, and Records come to mind off =
the top of my head, none of which can be represented by plain strings). =
What matters is if it's *easy.* And it's not. It's insanely hard. The =
only documentation that will tell me how to do that assumes that I'm an =
experienced Rails user; that I have a very solid grounding in Rails =
fundamentals.

When I downloaded Tango and its tutorial back in 1996, I spent about 30 =
minutes with the tutorial and said "Wow, that was easy, and it's doing =
just the things I think I want to be able to do. Neat!" I spent about =
eight hours with Rails, and said "Well, I still haven't been able to get =
my data into a browser window yet, and that's just the first step. Maybe =
there's something else that will be easier."

It took me less than two hours to start playing with Ruby objects that =
were populating themselves from my Postgres database using Sequel. Even =
though I didn't need to tell Sequel how to handle the UUID fields (it =
defaulted to turning them into strings), I *did* find the information I =
would need if I *had.* Is Sequel 'better' or more capable than =
ActiveRecord? I really don't know. Did its documentation make it easier =
for *me* to do what *I* need to do? Unquestionably.=20

I spent two hours with Padrino before I ran into a problem that I was =
unable to solve from the documentation. Nor were the helpful folks in =
the #Padrino IRC room able to fix my issue. I'm sure it's *possible* to =
make it work, but again, I'd spent a fair amount of those two hours just =
trying to hunt down answers to fairly trivial issues. So I decided to =
look at the other strong candidate on my 'frameworks' list, Ramaze.=20

Two hours of work with Ramaze had me with a browser full of data from my =
database.=20

There's no doubt in my mind that Rails has more out-of-the-box =
ready-to-go functionality than Ramaze. But the overwhelming majority of =
Rails-world is intensely infused with the philosophy that, while you =
*can* make your web site any number of ways, what you *want* to do is =
start with your Ruby objects, and be able to switch from one data store =
to another at a moment's notice.=20

Rails and its cloud of associated components are clearly groovy nifty =
tools. But just as clearly, they are not the right tools for *me.*