Slashdot Mirror
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.
← Back to Stories (view on slashdot.org)
You are, or at least so far as hype == marketing.
"It is a good divine that follows his own instructions" - Portia, The Merchant of Venice
Back when I was a young whippersnapper, we called that thing a relative record number!
People have discussed this over and over and over again. I presume you're talking about support for composite primary keys. They aren't necessarily a good thing. Go read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-youre-new-to-series-ive.html
I don't even consider normalization taken to the extreme, to be a good thing. It's a trade off, just like everything else - what you gain by normalization, you might lose in the form of added application complexity, or perhaps even something else. Just because normalization is "good" according to ivory-tower database theory, doesn't mean that anything that isn't fully normalized is "bad" or "broken".
"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."
Can you explain what exactly it is that makes it a lot harder? (And isn't a DBA paid to do his job?)
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.
While Rails might not be my first framework of choice to implement Digg in, I prefer to build sites which actually, you know, make money by solving problems for paying customers. When you do that, you don't really have to worry about scaling to infinity and beyond, but you do have to worry about expressiveness, maintainability, and time to market. (If you have too many customers relative to servers, heck, easy solution there -- the engineer in me says "just throw up more boxes", but the businessman in me says "pay somebody to worry about it so I can go back to counting my benjamins".)
I have a Rails site, my first (hopefully of many) for my small business, which plugs along at about 20 requests a second in tests. If I could saturate those 20 requests a second, I would quit my day job on the spot. Scaling? Eh, who cares.
(P.S. Day job is writing enterprise level crud apps for Japanese universities on the J2EE stack. They worry a bit about, e.g., getting hit with 8k users signing in simultaneously during class registration. You know what we do? Exactly what I'd do for a Rails app in the same situation ("don't do anything stupid like an n+1 queries loop, cache the important stuff, and buy enough hardware for the job"). Only difference in Rails is I have never wanted to poke my eye out with a spoon while writing it.
Help poke pirates in the eyepatch, arr.
Ever notice how those most "concerned" about scalability tend to have never profiled or benchmarked their own code? ... or understand why you want to scale horizontally, rather than vertically? Whenever I build services that can handle 120,000 requests/sec., they usually just end up being 99% underutilized. Everyone likes to think THEY will be the next MySpace, with no server budget apparently. I highly doubt that any who argue Rails can't scale has ever had to deal with real distributed clusters. The database cluster will have many more scalablity issues than the webservers. This is such a non-issue, I cannot believe it. If you can scale JAVA!!!... You know what I mean.
Yeah, and thats what I don't really like about frameworks in general. They have all of these awesome cool fast easy to use things built in. But sometimes you discover that your needs are too complex for the framework, and someone instantly replies " you don't have to use feature X". Well sooner or later you aren't using many of the cool features of the framework anymore. So why are you using the framework?
Well.. maybe. Or Maybe not. But Definitely not sort of.
Please just try Rails for a little while. While Rails has its flaws, overall it's a highly productive framework - and much of the credit for the terrific code clarity goes to Ruby, which is much more powerful and dynamic than almost any other mainstream language(other than maybe Javascript)
:conditions => {:status => 'pending'}) :pending, :conditions => {:status => :pending}, and then be able to change the previous example to:
Some things to read about and try within Rails:
* ActiveRecord's ability to introspect the DB schema at runtime. e.g. autocreating the method to allow: User.find_by_name('Joe')
* ActiveRecord's magic-fields, e.g. created_at/updated_at
* the ActiveRecord associations, and the easy DB queries that come with them, e.g. @user.posts.find(:all,
* the scope_out plugin, which provides some nice additions to 'with_scope'. e.g. in the Post model you could do scope_out
@user.posts.pending
* ActiveRecord callbacks and the controller before/after filters
* the RESTful routing and easy links that come with it, e.g. link_to(@user.name, @user) will create a hyperlink to the correct URL for that user record's 'show' page
* the form/field helpers which also integrate with the routing, so you can now do just form_for(@user) - it will create a proper form tag for hitting either the create or update method for that @user, depending on whether the record has already been saved to the database - the form_for/fields_for block syntax is also very powerful, especially when you add your own form helper methods
* all the convenience methods provided by active_support, like 5.minutes or 1.month.ago
* Ruby itself - Ruby is simply a joy to code in. even if I were going to dump Rails, I would now strongly prefer to find a new Ruby framework(like Merb) than using another language
I'd strongly urge you to pick one or more of the PHP MVC frameworks to look at while you read about Rails. Most of them are copies or at least inspired off Rails to some degree, so they often use similar conventions. You'll see the difference between what's possible in PHP and Ruby - PHP doesn't come out looking too good at the end
That stored procedure is awesome (well, it actually isn't very good sql, but it doesn't matter right now). As the developer, you just need to worry about passing the monster name and the database spits out everything you want.
If you do most of the logic in your stored procedures, it makes it easy to bolt on new features written in various languages. If you decide to have a perl script for a cron job, you just call the same stored procedures your ruby app is calling. If you want a windows front end for your admin staff, the windows app calls the same stored procedure too.
Once you bury the database logic in the application code, you have to rewrite it for every application. It is, in a way, a very evil form of copy & paste programming. Now every change in the database requires you to go into every single application and change something. Kinda like when you get slutty with your code and copy & paste it rather than abstract it out into a library.
And I'm aware stored procedures don't play nice if you are worried about cross-database issues because you sell the software. This only works when you get complete control over the application & database stack.
PS: MySQL stored procedures suck. Use a real database with a better stored procedure language.
You're assuming that all composite primary keys use values that do change. That's highly unlikely, given the number of tables in the world filled with historical data. That said, I agree (for other reasons) that surrogate keys are much better.
When you as a DBA use anything other than a surrogate primary key, you are making the exceptionally dangerous assumption that the client has the correct understanding of what their model entails, that there will be no exceptions to the rules of that model, and that the model they gave you will never, ever change.
Borrowing from your SSN example, let's say that your client tells you the main way they identify customers is through the SSN, and you go by that, and then there's a case of identity theft and the customer's SSN number has to be changed? Now you've got potentially thousands of records with a bad primary key that you have to change (and mitigate constraint issues as well). What if privacy issues require the company dropping SSN's as an identifier, and now the company will be forbidden from asking customers their SSN's? You'll no longer be able to generate primary keys compatible with the same ones used before.
What truly separates a good DBA from a bad one is the good DBA's ability to anticipate change, design for change, insulate existing stuff from change, and basically save the client from any flaws in their own conceptual model (while making it look like they've followed the client's conceptual model to the letter). A bad DBA simply trusts whatever his client says and believes it to be correct and forever immutable.
Ergonomica Auctorita Illico!
You are completely incorrect.
If your domain model describes the way an actor finds an entry is by Order# and Line#, that should in no way, shape, or form decree what your technical artifacts look like.
The correct thing to do in that case is to have a unique, opaque, identity key (numeric or guid, just so long as its unrelated to the record data, and has no additional meaning beyond the unique value of that record).
Then you can also add unique constraints or indexes to the composite key, and/or you can enforce that unique constraint in the application. Or both, for the smart ones.
But you need to have a unique way to identify the record THAT IS NOT SUBJECT TO CHANGE. In your example, you could re-order the lines, or one line could have been a mistake and you need to move it to a different order.
If you've used composite keys on order# and line#, then you've got alot of cleanup work to do after your change.
If you've used proper opaque identity keys, then you just change the data, and there are no side effects.
Since in that case your joins are also done on the identity keys, your relatinoships are stable even when you change order# or line#.
The SSN one is even worse. I can guarantee you that if you do that, someone will have the wrong SSN, and it will need to be changed in your data.
If you've used SSN as the primary key, then its a pain in the ass, and you have to do data integrity cleanup.
If you've used a proper opaque identity key, then you just change the SSN, and there are no side effects.
This is stuff you learn the first time you write an app as a junior developer without a mentor, and use SSN as a key. A year or two later you come to regret it, and the lesson is learned for a lifetime.