Well, you can look around more at [link] I haven't put up much content yet, but you can get the idea.

Thanks.

Weirdly I suddenly had a flashback to RPG. It shares a "Well, we both know there are some fairly consistent things we can leave as subtext." Not to to mention the whole neat angle on data.

I came out of a Modula 2/C++ place with respect to data when I left school and bumped into the real world of code. I was so relieved to find out that I wouldn't need to be coding link lists 40 hours a week. Hell, the language automatically iterates through your datasets! That's a hell of a shared assumption. Which worked perfectly where we were using it.

But when you didn't want to? OY! I worry about RoR making everything looking like a nail.

RoR is quite narrowly focused. It's only useful for web applications with fairly simple database requirements and where you have good control over the deployment environment.

One of the weaknesses of RoR is that it spurns many useful features of relational databases. It has no support for using foreign key constraints or stored procedures, and if you try to use them anyway it can be quite painful.

Another weakness is deployment. You pretty much have to use FastCGI or something even fancier, like apache with mod_proxy fronting a cluster of mongrel web servers if you are going to host a largish number of users.

I'm surprised at the lack of support for foreign key constraints. That's one of the things I find annoying to duplicate when I'm trying to be a good little MVC girl.

But I can see the stored procedures thing. I want to use them to fake atomicity, but I can see where that might get in the way of their desired stratification.

Oh, and what's up with the web server reqs?

My understanding is that it's hard to get the update order correct automatically in the face of foreign key constraints. It could probably be done, but the authors of Rails don't feel like it's important enough to do. And it would probably be difficult to maintain across database servers.

The server requirements are due to the fact that a Rails app is expensive to load the first time. If you tried to run it via CGI and paid the load cost for each transaction it would be too slow. So you have to keep it resident, either via FastCGI or something like mongrel.

Rails is also a single-threaded framework, so each running instance of your application can only handle one request at a time. This usually means you need to run a couple of instances in a cluster to get quick enough response times.

This is changing, though, as someone has created an apache module (http://www.modrails.com/) that can host Rails applications.

God bless the geeks and the things they'll give away.

eta:

This usually means you need to run a couple of instances in a cluster to get quick enough response times.

How out of the box is this? I mean, if I install the RPMs on my box, have I gotten myself into the web server config business?

It has no support for using foreign key constraints or stored procedures, and if you try to use them anyway it can be quite painful.

OK lost me at no support for foreign key constraints. Maybe it is a matter of having written too many applications where FK contraints were critical. But I don't think I'd like the design philosophy of a system that considered foreign key constraints "not worth the trouble".

Not as strong on stored procedures. But really, there are occasions when they are critical too - as in you want to use a database, but you want to make sure you maintain security and integrity even if someone accesses it outside your application. Of course most databases have ways of turning stored procedures off.

Anyway, I admit there is more room for argument on stored procedures. But no foreign key contraints? Huh.

How out of the box is this? I mean, if I install the RPMs on my box, have I gotten myself into the web server config business?

Before mod_rails, you had some significant apache configuration to do. With mod_rails it might be easier.

But I don't think I'd like the design philosophy of a system that considered foreign key constraints "not worth the trouble".

It's a lot of trouble to figure out from the constraints what a legal order is to write a set of mapped objects to the database. In fact, there may not even be a legal order.

That's not to say Rails doesn't provide some very nice validation tools. It just that they choose to do it in the application layer, rather than the database layer. Certainly a more appealing approach for an application writer than a database analyst.

At the very least, reading the framework docs helps tidy up my thoughts for code that perhaps doesn't warrant full Ruby on Rails treatment. MVC is dreamy.

I hate validation beyond about every other bit of coding, and streamlining the reporting and presentation was always frustrating. I like seeing how others do it.