Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

Standup 10/6/2008 – Namespaced controllers and MySQL ordering

Nathan Wilmes
Monday, October 6, 2008

Ask for Help

David and Jonathan are having trouble with testing namespaced controllers using RSpec. They have two controllers, Admin::MyController and SuperUser::MyController, and the RSpec tests appear to be finding the wrong controller.

Their short-term solution is to put a manual require in the spec that was getting confused.

UPDATE – The issue turns out to be a naming conflict. The app has a model named SuperUser, and the existence of this model can cause class loading to be confused for SuperUser::* controllers. In Socialitis, our standard is to use plural names for controller namespace names, to prevent this sort of confusion.

Interesting Things

Steve has learned that, in general, it’s a good idea to avoid using offsets when manipulating large quantities of data in MySQL. Luckily, some of MySQL’s quirks help with this:

  • MySQL sorts indexes. The primary key is the main index that it sorts.
  • Any select without an explicit order clause will pick an index, then return data in sorted order by that index. Again, usually you’ll see the primary key first.
  • You can take advantage of this behavior to paginate through a large dataset where the order doesn’t really matter. The following statements perform better than your typical LIMIT/OFFSET clause:

    SELECT * FROM big_table WHERE id > 1 LIMIT 1000
    SELECT * FROM big_table WHERE id > 1000 LIMIT 1000
    SELECT * FROM big_table WHERE id > 2000 LIMIT 1000
    
  • acts_as_solr uses this technique for reindexing.

  • Also, inserting a record in the middle of an id ‘hole’ is not a very good idea in MySQL, because the database then puts a great deal of work into reordering all of the later records.

Here’s a link to a related blog post:
http://weblog.jamisbuck.org/2007/4/6/faking-cursors-in-activerecord

  • 0 Shares
  • Share on Facebook
  • Share on Twitter

Add New Comment Cancel reply

Your email address will not be published.

Nathan Wilmes

Nathan Wilmes
San Francisco

Recent Posts

  • Performance tuning an old Pivotal app – how I did it
  • Standup 2/24/2001-2/25/2001
  • Standup 2/23/2011 – mocking AJAX for jQuery 1.5
Subscribe to Nathan's Feed

Author Topics

agile (14)
testing (3)
ruby on rails (1)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >