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:
>> 
>> 
>>> Dave Howell wrote:
>>> 
>>>> The piece I couldn't find was "How do I tell ActiveRecord to convert the 
>>>> database's "UUID" type to a string, and vice versa?"
>>>> 
>>> Ah, I've never come across a database with a "UUID" type. I'd imagine AR 
>>> would treat unknown types as strings, but you'd need to try it.
>>> 
>> 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.
>> 
> 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. 

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

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. 

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. 

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. 

"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. 

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. 

"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. 

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. 

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. 

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

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. 

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