Ruby on Rails 2.0 is Done

Jamie noted that ruby on rails 2.0 is done. In addition to upgrade and installation instructions, the article lists a number of the more interesting new features in the release which appears to be quite extensive.

Comments

ORM still broken?

[poet]

I wonder if they still disallow proper database design by having a requirement of an autoincrementing number for the primary key.... The Rails developers could learn a thing about databases. Start here: http://en.wikipedia.org/wiki/Database_normalization . Yes I know that a serial/autoincrementing key makes it easy for the app... it makes it a lot harder for the DBA in a lot of cases.

Re:ORM still broken?

[K. S. Kyosuke]

Making the huge mistake that everyone would only ever want to do something your way is how you kill a programming language.

What a relief... As a lisper and rubyist, I'm glad to hear that Python is going to die! Good riddance!

Re:ORM still broken?

[FooBarWidget]

That's great for you, but Ruby on Rails is not - and isn't intended to be - a framework for redundant distributed DB applications. Ruby on Rails is not trying to be the thing for everybody. And that's exactly what makes it so powerful and easy. Indeed - turning it into something for everybody actually makes it worse. I'd like to see some proof that composite primary keys are so important in web applications. So far I've seen no convincing evidence. Despite all the complaints about composite primary keys, new Rails websites are written everything, even by high-profile organizations like IBM, NASA, Oracle and Yahoo. And they seem to function just fine.

If you really, really, really, really need composite primary keys, you can still fallback to raw SQL queries in Rails.

Re:ORM still broken?

[crayz]

If you do a search for "composite keys rails", hit #1 is this, a gem written by a fairly prominent ruby programmer that makes it trivially easy to use composite primary keys within ActiveRecord. My guess is if you actually cared about this issue, rather than just raising it as a canard to bash Rails with, you would have found this solution to your problem and wouldn't be posting here

Re:Scaling matters if you're Digg. Are you Digg?

[slaingod]

Every time a RoR article hits Slashdot, there is a scale/speed question that gets raised. Realistically, there are a ton of things you can do to get performance where you want it to be. The first is to dump mongrel and use FastCGI or similar. FastCGI is 3-5x faster than mongrel. Mongrel is great for low traffic sites, and for dev, don't get me wrong.

The upper limit I see with RoR/FCGI is around 2500 requests per sec, for a 'is the server alive' ping, that simply returns 'Yes'. Typical, results are in the ~100 requests per second range with moderate db access, and rendering to xml or html. 100 requests per second was enough to handle a 24 hour media buy on the frontpage of myspace for example (100,000k unique visitors-ish).

Moving your static assets off of your server and on to S3 or another CDN is obviously a big help here, so your server/bandwidth is only taken up with requests that need/affect the db. From the example above, with the MySpace media buy, the total for that day was $20-30 I believe in bandwidth costs, and this was a site with a video mixer that had tons of images/video/mp3 and large flash objects. Obviously, mongrel shouldn't be delivering your assets locally anyway, apache/lighty etc should be.

Ultimately it comes down to design and caching when it comes to getting that top performance out of it. My 100 requests/sec wasn't using MemCached or fragment caching, and the mysql db was local. Caching in Rails is a little less than helpful for highly customized for each user sites, but there are plugins that extend it like extended_fragment_cache(ing?), that allow you to templatize things like ID's, etc. Think of say a forum topic listing, where only the topics change as you paginate. With extended fragment caching, you basically draw the page once, and then pass in a hash of the variables that replace the placeholders each time you draw a new page.

Another big thing with ajax sites, is to use link_to_remote with the :update => 'some_div', rather than using the rjs/render :update stuff in the controller. escape_javascript is one of the BIG performance issues in Rails, as it is basically just multiple gsubs. Designing around that is a big win. A native C escape_javascript should be a high priority for the rails/ruby devs, with optimization for the memory allocations (ie. scan the string to see how much it will grow, allocate, and just do one pass to expand).

Re:You don't have to use ActiveRecord

[smackjer]

I agree. That's why I build all of my computers by hand with raw transistors and whatnot.

Comment removed

[account_deleted]

Comment removed based on user account deletion