On Jun 11, 2010, at 10:31 , Walton H. wrote:
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.
