Database Constraints, Stereotypes, Rails, Culture, Talmud, Gender, MINASWAN, Religion. But ABSOLUTELY NO BONDAGE PLAY

Posted by amy on November 02, 2007

This post started out with a plan to compare constraints in software to bondage play, and suggest that DHH is a top who likes to constrain others (“opinionated software”) but is extremely uncomfortable being himself constrained (by, say, the database). I was going to suggest that DHH maybe needs to get a little bit more confident and comfortable being a ‘bottom’.

Now, that would have been a wildly, wildly inappropriate post, don’t you think? So it’s lucky for me that as I was writing it, I realized that not only was it inappropriate, it was completely unfair. So this post is still about rails culture, and still about database constraints, but I am not, I repeat, NOT arguing one way or another about DHH’s predilections in bondage play (assuming he has any, and if he does, not that there’s anything wrong with that ), about which I am, and hope and plan very much to remain, ignorant.

That out of the way, how did this all come up? Yeah, my mind’s a little twisted. But here you go:

My friend and partner-in-teaching-crime* (well, boss in teaching-crime, technically, and is teaching really a crime? To my students: do not answer that!) John complained recently about the difficulties of writing a migration to turn a plain HABTM join table (two foreign keys, no primary key, nuthin’ else) into a join table with state, linking two other tables with the :has_many :through association. Unfortunately, as he describes, ActiveRecord won’t let you add a primary key column to an already-existing table, so he had to migrate all the data over to a new table.

Couldn’t you just drop down to “execute ‘db-specific sql here’”? I asked.

Yeah, but you wouldn’t be database-agnostic, of course. John likes to be agnostic. He has historical reasons for that, just like I have historical reasons for thinking that ads comparing servers to who won’t give blow jobs are kinda offensive. But anyway, I don’t have those reasons that John does to prefer agnosticism. I figure that in most cases, people are sticking with the database they’ve got, so database agnosticism isn’t that important to me. The ORM is one of Mr. Spolsky’s leaky abstractions, and while that’s no excuse to start poking extra holes through just for the fun of it, I don’t have any need to pretend that the holes that exist aren’t really there.

In any case, I drop down to the database to put in foreign key constraints.

[Aside: John said in email:

"There is a distinction to be made between this narrow case of
agnosticism (fiddling with keys) and the general case. The narrow case
is easier to disregard. In the general case, it is very difficult to
argue against agnosticism, because the primary driver is: You get to
know less. That is frequently (more frequently than not) beneficial,
right? In the general case, I would rather write
user.find_all_by_last_name rather than the raw SQL. etc."

I agree wholeheartedly, and in that sense I too am in favor of database agnosticism. But obviously we have different levels of allegiance to the idea, because I would never have put in the effort to come up with a database-agnostic migration from a HABTM to a has many through relationship, and he did. Maybe it's just that I am lazier than he is, though...]

So this post was going to be about how it is the rails way not to use foreign key constraints at all, but to rely on ActiveRecord and your own unit testing to maintain data integrity. (hah!) And I was going to say “that’s freakin’ insane and evidence of all that is wrong with the whole culture of Rails.” But while it would be fun to see what this temporarily did to my site stats, (assuming it got dugg or reddited or something) it wouldn’t be fair.

I found very little evidence that not using foreign key constraints is considered to be a best practice by most people in the rails community. The main thing is this caboose posting, from last year. This was mostly a complaint about how big of a pain in the ass foreign keys are, especially where fixtures are concerned. But it actually only at the end claims that foreign keys are not needed, if you are using ActiveRecord Associations correctly. And even then, it’s a weak claim, about foreign keys in the development database:

The time thing sold me on not using foreign keys in development. I’m sure there are a number of arguments that can be made for using foreign keys etc etc, but it’s just stuff that gets in the way in a framework like rails. Do we test w/ foreign keys in place before milestones(what I’m leaning towards)? Do we test w/o the fks in place(obviously not :])? Maybe somebody can come up with a better way to handle them, but I don’t really think you need fks if you’re using rails associations correctly. If you are forced to use them though, the above approach might be a good place to start.

Okay, I found one other posting, from a guy who gave up his foreign key constraints (and wept) because they were too hard to use with fixtures. But most people in the comments of that post seems to think the problem there is not foreign key constraints, but fixtures, and that dropping the reliance on fixtures would be the smarter thing to do. Or fixing the fixtures, or whatever.

DHH has nothing to say on the matter that I could find. In AWDR, Dave Thomas explicitly advocates the use of foreign key constraints (2nd Edition, p. 324). Mostly what I found on the web about rails and foreign key constraints was a bunch of people talking about how they do use them and you’d be crazy and irresponsible not to. Yes, people differ on when in the development process they put them in (in fact, right this minute I have a development database with a near-complete lack of foreign key constraints, my rather pathetic excuse being that the client’s requirements are so changeable right now that we can hardly keep up with the foreign keys themselves…), how they use them with fixtures, and other details, but I really found very little evidence that anyone in the rails world seriously advocates putting into production web applications backed by databases without foreign key constraints. Relational database technology is mature, it’s well-tested, and it’s logical. I trust it much more than I trust either my own code or DHH’s. Database constraints are easy to use and good for you, just like flossing. And that appears to be the majority view.

So the evidence wasn’t there, and I had to rethink this post entirely. And so it’s become, in part, a post about stereotypes, and about culture, and about the ways that people confuse technologies, creators, fans, and users.

Rails is a technology. The technology exists in the context of a culture. The culture is greatly influenced by the fact that a single, very opinionated, um, strong personality developed the technology. Certain kinds of people are attracted to the opinionated personality, and become involved in the technology and its culture because of that. This is great for adoption of the technology. But then you get the fanaticism: rabid pro-Rails trolls who jump down the throats of people they perceive to be deviating from the One True Way of DHH. And equally rabid anti-rails trolls, screaming “Twitter”!

Now, is all this clash of personalities and hue and cry integral to the development of the technology, or is it epiphenomenal? (Is that a word?) I’m not sure. The anthropologist in me says it is, and that the culture of rails in some sense IS rails — drives its development, ensures or prevents its success, etc. The Marxist in me thinks perhaps the structure of rails itself is responsible for the culture surrounding it: the culture reifies the framework. And the poststructuralist in me suggests that, however determined things appear to be, however narrow and defined and boundaried and opinionated and one-true-wayed things appear, there’s always space for something else to arise.

There’s the One True Way of DHH. There are rabid fanboys. We talk of drinking the kool-aid, and we laugh at video advertisements comparing the separation of concerns, database-agnosticism, and ease-of-use of Rails to PHP, Java, et. al. “With rails, I can build a blog in 10 minutes,” we say. With rails, we never have to code again! Let’s just go to the beach instead! There was the Twitter developer scaling scandal, and the CDBaby switched-back-to-php-from-rails scandal, and a bunch of scandals I haven’t even heard of, no doubt. There’s the rails bandwagon, the rails hype, rails lets crappy developers wreak havoc quickly, rails is too slow, and rails is not ruby.

And that’s all fine and part of the fun, and part of the DHH Is Opinionated and So We Are Opinionated – ness of Rails culture.

But then there’s the technology, and lots of quiet, not-so-opinionated, flexible people who are using Rails because it’s a pretty good, pretty easy framework that helps them get their work done. There’s plenty of that too. And there’s no need to decry the partisan atmosphere of rails culture with a great big rending of garments about how the culture really has to change if it’s going to achieve more popularity, and it’s scaring people off because it seems too hyped, and badly executed rails projects are giving rails a bad name and how can we police that, and so on.

Let’s just all get on with our work, using rails, or not, as the work dictates. And in a mild-mannered matz-y way, talk about what we are doing, and why, and how, and what we like, or don’t, about it.

For me, rails is a web framework, not a religion. I know that not everyone feels or acts that way, and that’s fine for them. They can wave their hands and argue about what constitute a ‘scale’ for the purposes of determining if a fish is kosher, or if one should use foreign key constraints. Me, I’ve got to get dinner on the table.


* Max would like it noted that he thinks there’s something very trite about the expression “partner-in-crime”. He’s right, of course, but I think I’ll leave it in anyway, to annoy him.

Popularity: 25% [?]

Theoretically Related Posts
  • how did I ever live without xkcd?
  • Why We’re Learning Ruby on Rails
  • REST vs. SOA: thoughts from a member of the unwashed masses
  • Fearless Play. Or, What We Did in 2007
  • Trackbacks

    Use this link to trackback from your own site.

    Comments

    Leave a response

    1. Mark Van Holstyn Fri, 02 Nov 2007 19:07:04 UTC

      re: Unfortunately, as he describes, ActiveRecord won’t let you add a primary key column to an already-existing table, so he had to migrate all the data over to a new table.

      What about add_column(:some_join_table, :id, :primary_key)?

    2. amy Sat, 03 Nov 2007 08:50:03 UTC

      I haven’t tried it myself, but John and others say it doesn’t work, and I have no reason to doubt them. have you had success with it?

    3. Mark Van Holstyn Sat, 03 Nov 2007 15:01:28 UTC

      I have done that many times in the past, and it works great for me. What do John and other say is the problem with that?

    4. amy Sat, 03 Nov 2007 19:32:44 UTC

      Mark, you are so right! It works just fine. Apparently John read on the rails wiki that you couldn’t do it, and he took their word for it. And the rails wiki just happened to be wrong, or perhaps was reporting an old bug that was no longer a problem, or whatever. Thanks for insisting it could be done. Next time I’ll just try the darn thing before posting… ;)

    5. Kramer auto Pingback[...] Database Constraints, Stereotypes Rails, Culture, Talmud, Gender, MINASWAN, Religion. But ABSOLUTELY… November 2nd, 2007 at 8:19 pm [...]

    Comments