Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Standup 06/15/2009: If at first you don't succeed

Interesting Things

  • A few people are looking for an electronics recycling center that doesn’t charge an arm and a leg. Word is there are centers that will take pretty much anything electronic in San Carlos and by the Fruitvale BART.
  • Ruby 1.8.6 segmentation fault: A couple teams have had trouble upgrading to the Ruby patch to fix the recent segfault bug. XML parsing and SOLR seem to be the most common culprits. They’re working with EngineYard to figure out the problems.
  • On a related note, EngineYard is now the official maintainer of Ruby 1.8.6.
  • A few Pivots attended an RoR outreach meetup at Orange Labs this past Saturday. Sarah Allen organized the event with a focus on introducing more women to Ruby and Rails. It was, by all accounts, a great success.
  • After seven months, and much rabble-rousing, this patch, refactoring the definitions of through association classes to use composition rather than inheritance, has been committed. Let this be a lesson to you: persistence can pay off.

Ask for Help

Non-numeric primary keys: fact or fiction?

We have one project that has considered using non-numeric primary keys in their MySql database. Enquiring minds want to know if this is a reasonable idea. General consensus was no:

  • It makes Rails unhappy.
  • It might make plugins unhappy.
  • It might be slow (some debate on this; searching on an indexed string column is reportedly equal in performance to searching on an indexed numeric column in MySql).
  • The benefits are unclear.
  • Just don’t do it. For reals.

  1. Dan says:

    Wow, the process for submitting refactorings seems like a real WTF. I wonder if it would be possible to target the N most important plugins and use some CI magic so that good refactorings that can be shown not to break those plugins could be accepted more readily. Anyway, congrats!

  2. Mark Wilden says:

    By nonnumeric primary keys, I presume you’re talking about UUIDs? If so, we’ve done it, and fairly painlessly. There are some gotchas, like not being able to assume find(:last) returns the most recent insertion, but it’s eminently doable.

    There’s no way searching a wide column is going to be as fast as searching a narrow column. The wider the column, the less data that fits in memory, and the more disk accesses.

    That said, the reason we’re using UUIDs is to be able to shard our database out to multiple servers, which is for speed/scalability.

    If, on the other hand, you’re talking about using “meaningful” values for your primary key strings, such as usernames, don’t do it. It’s fine to use meaningful data for unique, candidate key columns, but you don’t want to base your relational integrity on it.

  3. Steve Conover says:

    According to this post:


    char:char joins are only 6% slower than uint:uint

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *