Ruby on Rails 2.0 has been released. “Rails 2.0 is finally finished after about a year in the making. This is a fantastic release that’s absolutely stuffed with great new features, loads of fixes, and an incredible amount of polish. We’ve even taken a fair bit of cruft out to make the whole package more coherent and lean.” On Zenbits, they give tips on how to install 2.0.
Congratulations to Rails team! Rails changed the way we look at web application development.
And it’s ironic that I learned about the final release exactly here, on Osnews, where I also first heard of Rails!
I’ve been running on edge Rails for a while, and I’ve been really enjoying it. The dev team has done well, moving non-core functionality into plugins, while incorporating plugin features that are superior to ones contained in the core (sexy migrations are a good example).
This will be the future of Rails development, as pretty much any feature can be developed as a plugin (Ruby makes this possible), and if it’s proven to be an improvement to existing functionality, it will then be considered for admission to core.
On another note, if you still find Rails to be too ‘big’, I’d suggest taking a look at Merb (http://merbivore.com/). It doesn’t come with as many ‘goodies’ as Rails, but it is thread safe, plays well with Haml and ActiveRecord (as well as other ORMs). Check it out. The downside is that there is not as nearly as many plugins available (Rails biggest strength IMO).
@openwookie: Rails 2.0 is definitely a welcome upgrade from previous versions. Even the view helpers alone feel much more intuitive than the 1.2.x series.
I’m also a merbivore like yourself. If Rails was rewritten from scratch with all of the lessons learned over the past 3 years you would pretty much have what merb is today. What excites me the most is you get rails-like functionality at twice the speed and 1/2 the memory usage.
Rails is awesome, some of the new database migration changes are really great. The db migrations in general were an ingenious addition! creating databases, tables, columns and adding test/sample data all with simple scripts, completely platform and database agnostic. No SQL, all ruby. amazing stuff.
The RESTful additions are nice as well. I cant wait to get my hands dirty with that stuff. Congrats Rails Team!
Anyone who is a rails fan, but works in the asp world, check out ScottGu’s blog for info on the upcoming MVC framework for asp. They actually hired Rob Conery for it, who is the lead developer for subsonic (an opensource OR/M that brought ActiveRecord and REST to .net)
Long live ‘good’ MVC. I’m stuck using one of the crappiest implementations of the concept that I’ve ever seen, and I’d much rather be without its “help”.
Rails makes development sexy!
Is it possible to have compound primary keys in Rails 2.0? I remember reading that the Rails developers explicitly rejected compound primary keys in Rails 1.0 because they thought there was no legitimate reason to have them (in their eyes) and that any legacy system that used them should be rewritten “the right way”.
It’s possible to create a Rails-type system with compound primary keys and user generated sequences (see http://framework.zend.com/manual/en/zend.db.table.html ) which might not have been obvious at the time the Rail developers made that statement was made (since Rails was a pioneer). So I’m wondering if they’ve changed their minds and included this functionality in 2.0?
You only need compound primary keys if you want to use a legacy database.
If you are designing a database for a Rails app from scratch you are still expected to have a column called ‘id’ that is the primary key in each table.
Now that the ids of rows are used to build up the RESTful urls, it has become harder to not use this convention. For example, if you have a url of /posts/1/comments/3 the ‘1’ and the ‘3’ are the primary keys of the post and the comment. If they were compound primary keys, you would probably end up with a pretty messy looking url. As well as needing to special case the models for compound primary keys, you would also need to special case the config/routes.rb file that generates the urls.
It still doesn’t.
But why do you need compound primary keys? What are its advantages over using a number? I’ve never felt the need to use compound primary keys.
I’ve always felt slightly off about creating an arbitrary unique value unrelated to the actual context of the data when there is already available a way of uniquely identifying rows that only uses actual system data.
Also, by default most DBs create an index on the primary key, which is a bit meaningless with a created single key when most/all data access will still be by what would otherwise be the compound primary key. Just means you have to create an additional index, i realize, but there ya go.
So no real technical show stoppers, just a couple of things that kinda run against the grain for me anyway…
Is it possible to have compound primary keys in Rails 2.0? I remember reading that the Rails developers explicitly rejected compound primary keys in Rails 1.0 because they thought there was no legitimate reason to have them
The only reason to use them is for legacy database reasons, but even then, you’d be better off refactoring and normalising your database design – although, as borker says, I’m not keen on having peripheral stuff in my databases that isn’t related to the actual data.
Edited 2007-12-07 23:25
An interesting link with a discussion on composite primary keys:
http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_prima…
I’ve read it all and now am really asking myself how ignorant can the Rails developers get?
Summary: Rails encourages sloppy db design!
I read the discussion and about half the people making the comments disagree.
Identity key sequences are used for primary keys in Rails because DHH and others are of the ‘opinion’ that way is better, not because they are sloppy db designers. Rails is ‘opinionated’ software, and if you don’t agree with the principles on which it is designed then you are free to use another framework. They would rather keep Rails lean and simple, instead of trying to be all things to all men.
“Summary: Rails encourages sloppy db design!”
“not using composite primary keys = sloppy db design” is merely an opinion, not a fact. The Rails developers disagree with that opinion, and Rails is opinionated software.
And I agree with the Rails developers. The website that you link to says that the autogenerated identity key is redundant because (CustomerID,ProductID) already uniquely identifies a table row. And he’s right, but that’s not enough reason *against* using an autogenerated number, I simply do not see the problem. Next, he says that using an autogenerated identity key increases complexity. Yeah in this specific case he might be right, but read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-you… for a rebuttal.
The biggest problem I see is that composite primary keys make foreign keys ugly and large. Furthermore, Rails uses the autogenerated integer identity key in URLs, for beautiful RESTful URLs. Can’t do that with composite primary keys.
And finally, how do you define “sloppy”? To me, a database design is good if it’s easy to understand, easy to maintain and easy to work with. The fact that composite primary keys makes foreign keys so large makes the database hard to work with (ugly and large SQL queries).
What it really comes down to is green field vs legacy. For green field projects, I’m going to come down on the side of autogenerated integer PKs. Sure, it’s an extra integer field per row. But someday, for some business reason, you are going to want to add or change the definition of the key. It’s a pain. It’s wrong. Also, when you actually go to *use* the PK to relate tables, you are comparing simple integers instead of big long-ass strings. So overall, you come out with lower processing overhead.
For dealing with legacy databases, DHH chose to write that situation off from the start:
http://tinyurl.com/35fbxj
Sometimes, when dealing with legacy data, the *right* thing to do has to be the painful and “wrong” thing that I mentioned above.
The Rails devs take a very “My way or the Highway” attitude with their users.
(I chose “the highway” and have never regretted it or looked back, btw.)
Well, so we have different opinions (although I could argue for there being only one sane opinion):
To me the most important aspect is a clean design that prevents inconsistencies in the data.
Of course you can use ids AND unique indices to achieve the same integrity – but – and that is a big but! I fear most of the developers who blindliy follow DHH opinion lead simply forget about that.
Well, that’s up to them then. I realize this since the very beginning, and I always use surrogate primary keys *and* unique indexes to ensure data integrity.
Also read http://www.nearinfinity.com/blogs/page/lrichard?entry=surrogate_key… for a rebuttal of the rebuttal
To me ids are necessary for tables which define things (like for example a table of cities) – they are “natural” in this case.
But for tables which link other tables together in relations (like an adress which has as part the fk city_id from the definition table cities) it is simply not natural to attach an arbitrary id.
Well, although I’m not keen on additional data, that’s the way Rails works and that’s the way that Scaffold works amongst other things. You have to weight up using Rails and Scaffold against keeping your data ‘pure’, as it were.
I started developing with Rails back in the 0.13 days, I bought both editions of Agile Web Development with Rails… I knew one or two things about Ruby and Rails.
But abandoned Rails as soon as I discovered http://www.webtoolkit.eu . It clones the Qt API but it outputs AJAX webapps instead of a GUI application.
Advantages? Many:
– Develop websites in C++, using the Qt API (that includes signals and slots)
– No need for bindings between Ruby/PHP/JSP and C libraries
– More third party libraries available than any other language
– You can build your application as a FastCGI module you can use with Apache/LigHTTP/IIS/etc, or as a standalone application with its own webserver
– It scales like hell: it can deal with more hits than Rails, PHP or any other will ever handle
– Beautiful widgets (ExtJS, http://www.extjs.com )
In a webapp I’m developing (for intranet use) I’m using Wt, Samba and Apache with the mod_auth_ntlm module to authenticate and authorize users without asking them to login: if they are using Firefox or Internet Explorer, I just look for their Active Directory credentials using mod_auth_ntlm (an Apache module, I’m compiling my webapp as a FastCGI module) and check their permissions using Samba: are they allowed to see this or that?. It works like a charm and it’s very easy to do. Can you do that painlessly with Rails, PHP or JSP?
Is it reliable? Their site seems to be down.
Here is what google has cached:
http://tinyurl.com/2rohon
It is reliable and yes, the site seems to be down now. You can download the source from Sourceforge: http://sourceforge.net/projects/witty/
Ubuntu packages are available at my PPA: https://edge.launchpad.net/~pgquiles/+archive
Koen Deforche, one of the guys behind Wt, is always eager to help in the witty-interest mailing list: http://sourceforge.net/mail/?group_id=153710
I don’t think you can use the words “C++” and “painlessly” in the same sentence.
Trust me, coding in Qt is nothing like coding in regular C++. It’s like a whole different language.
“””
“””
I find these comments interesting. It suggests to me that coding the interface can be such a pain that it overrides considerations as to what language is best for solving that actual problems. In general, I prefer a dynamically typed, interpreted or byte code language for… well… most everything. It is a pity that with web apps, the pain and general suckiness of coding the user interface itself overshadows the actual problem to be solved.
Edited 2007-12-08 18:43
I’m not sure if writing web apps in C++ is my idea of fun. I really like the way you can just change something in a Rails project and try it out instantly without needing a compile step.
There doesn’t seem to be a really comprehensive Prototype based widget toolkit, only individual widgets and some interesting extensions at the moment.
Jester is an implementation of ActiveResource written in JavaScript:
http://jesterjs.org
I thought this post was interesting, it shows how you can use Jester with Dojo data aware widgets:
http://mysterycoder.blogspot.com/2007/11/dojo-grid-jester-rails-res…
That would allow a Rails app to serve up a complete JavaScript widget based version of the app, returning the entire application code from a url like say /app. That code would then use ActiveResource and Jester to interact with the web server via RESTful urls.
The methods in the controllers could either return complete html pages for simpler browsers, or the xml for the ActiveResource widget based app. So you could write a single Rails app that would have multiple personalities; straight html, javascript widgets or active resource based web services.
I just downloaded 1.0. Yesterday.
Now it works!
Maybe they were updating something on the server.
maybe they needed to recompile their site. ;-p
maybe they needed to recompile their site. ;-p
:-). Joke apart, it’s an interesting concept. I’d heard of Wt before, but never looked at it much. Another thing to play with.
“””
Now it works!
Maybe they were updating something on the server.
“””
Yeah. But now the rubyonrails.org site is down. And it seems like Turbogears’ site and/or Trac is down about a third of the time I need them. Do these web framework devs not realize just how *bad* it looks when their own sites are down? “Here, use our framwork for your mission critical apps! Oops! Our site’s down again!” 😉
Edit: It seems that the folks at /. just got the news. So I suppose the RoR webmaster can be forgiven… this time. 😉
Edited 2007-12-08 19:25
Anyone know if this will be able to work with jruby or how much work it owuld take to support it etc?
if ruby 2.0 will also be released before new year?
I don’t speak polish…
Edited 2007-12-08 21:05