On Jun 8, 2010, at 7:11 , Brian Candler wrote:
> Aside: Rails (or ActiveRecord) expects that the primary key is called id".

Yea, but I'd already rejected that convention. 

create table Horses (
	horse_id primary-key-thing,
	ranch_id foreign-key-thing
	...
);

create table Ranches (
	ranch_id primary-key-thing,
	...
);

create table HiredHands (
	hiredhand_id primary-key-thing,
	ranch_id primary-key-thing,
	...
);
	
select * from Horses join Ranches using (ranch_id) join HiredHands using (ranch_id);

	as opposed to 

select * from Horses join Ranches on (Ranch.id = ranch_id) join HiredHands on (Ranch.id = ranch_id);

An ORM that makes the Ruby code cleaner by making the SQL code worse is not my friend. I do a LOT of my work directly in SQL.

> Now, I've written applications which connect ActiveRecord to an existing 
> legacy database which doesn't respect Rails conventions, and they work ine. 

Oh, I never doubted it that it could be done. My problem was that the overwhelming percentage of available documentation assumes that I *won't* be doing it that way, so that I couldn't find the information I needed to make it work. 

> So I'd say:
> * design and build your database how you want
> * connect ActiveRecord to it as above
> * watch it work
> * if you really get stuck, then look at other ORMs (but I can't vouch ow well they will work with the rest of Rails, at least before Rails 3)

Um, but I hadn't planned on using Rails at all. 

After setting up my models in Sequel, I started looking at frameworks. Padrino was the frontrunner, but it kept doing what Rails had done to me, just not as hard. The online tutorial included a feature that wasn't yet part of the version installed by rubygems (the -a switch), the 'bundle install' command that I was told to invoke without much explanation put some presumed-necessary gems in ~/.bundle/blahblahblah without telling me (and when I deploy it to the production server, there won't BE any home directory, so throwing crap in my home folder isn't satisfactory, especially if you don't tell me you're doing it), the 'admin' sub-app (I still have no idea what it does, I only know that the tutorial thought I'd be happier if I installed it) apparently took schema-write-access for granted and tried to create an 'accounts' table, and when "padrino rake seed" (and again, I still don't know what that command was supposed to actually do for me) failed with a cryptic database-related error, nobody in the #padrino IRC channel could help me resolve it. 

That's more or less the kind of experience I had when I installed Rails and started trying to evaluate it, except that I threw a personal "Unable to find solution in current documentation space" error after two hours on Padrino, whereas it was about eight hours before I gave up on Rails. 

So then I moved to Ramaze. Two hours of *that,* and I had a browser window full of data from my database. 

Winner: Ramaze. 


That just left selecting a templating engine. I figured I should be able to find at least a couple that would vastly exceed the templating functions I was used to from Tango, the DB-to-Web tool that I bought and loved back in 1997. 

I guess 'lightweight' is just too popular an adjective, though, because so far, I haven't even found anybody *claiming* to do what it could do, never mind living up to such claims. I did find a "paginator" hiding in Ramaze as a 'helper' (not in the templater, where I'd expected to find it, but that's probably my own error), but it's still going to need a lot of customizing to do what I'm looking for. 

Most of the templating tools out there are variations on a theme by ERB, which is pretty much the same as what I had with .idc/.htx files in IIS 2.0(?) running on Window NT 4.0 back in 1996. Except for haml. 

I haven't gotten to actually using Haml yet, but it took me about 30 seconds to fall in love with it. Barring catastrophic incompatibilities with Sequel &/or Ramaze (which seems highly improbable), I'm done evaluating, and have finally moved on to developing.