Featured Posts

The 10 Worst Things about World of Warcraft - Mists... I've been playing WoW since vanilla version starting in 2006.  Except for a six-month hiatus in late 2011, I've been a daily player.  I've seen multiple patches come...

Read more

Best Breakfast Burritos, ever! I like eating a good breakfast, usually around lunchtime once I've had my fill of coffee and am awake enough to appreciate a good breakfast. This is my recipe for my ultimate...

Read more

Testing Arrays in PHP - Back to Basics... Sometimes, when you're wallowing through your abstraction class layers, you find yourself using code for simple functions that are normally the focus of an Intro to Programming...

Read more

PHP: Comparing Object Structures I'm working on a project where I am converting an established REST API over to a rabbitMQ service.  Because, you know, dinosaur, I'm continuing to use PHP as my language...

Read more

Mountain Lion and Tunnelblick - Playing Nice Together One of the things that requires some tweaking after the installation of Mac OS X (Mountain Lion) is Tunnelblick, a free and open-source GUI for openVPN.  I use Tunnelblick...

Read more

Subscribe

BuddyPress — Pages failing to load (404)

Category : Technical
No Gravatar

I was going insane working on a buddypress install for our intranet’s tech-blog because every page I attempted to load into WordPress following the Buddypress install resulted in a 404 error.

Eventually, after several (re)installs, I tracked the issue down to a mod_rewrite issue.  Because I’m using sub-directories through a <directory> tag in my apache configuration, my .htaccess file looks different from the normal WP/BP installations:

# BEGIN WordPress
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /techblog/
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /techblog/index.php [L]
</IfModule>

I kept mucking about in this file thinking that there was something in my configuration that was incorrect causing me to 404 whenever I left the main page.

My boss inserted an error into the .htaccess file and, when we reloaded the page, we didn’t generate a 500 error — the site’s main page loaded, but the sub-pages were still broken.  That we injected an intentional error and the page loaded indicated that mod_rewrite was ignoring .htaccess and so the problem had to be further up in the food chain.

My <directory> alias was incorrect in two places:

Alias /techblog /var/www/techblog
 
<Directory "/var/www/techblog">
    Options Indexes MultiViews
    Order allow,deny
    Allow from all
</Directory>

First, I learned that you have to explicitly state AllowOverride All – the default setting was: AllowOverride None.  Which tells Apache to ignore the .htaccess file.  Deleting that line from my configuration did not have the anticipated effect of telling Apache to not ignore the .htaccess file; you must explicitly state AllowOverride All.

The second thing I learned was that you have to add FollowSymlinks to the Options directive so that your permalinks will be honored.  My configuration file now looks like this:

Alias /techblog /var/www/techblog
 
<Directory "/var/www/techblog">
Options Indexes MultiViews FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>

When I restarted Apache, the BP site correctly loaded the sub-pages without error.

 

Renaming mongodb Columns

Category : Technical
No Gravatar

Today I was putzing around in the geo-spatial collection when I noticed that I had an unhappy over one of the column names within the collection.

In the mySQL world, changing a column name is pretty straight-forward courtesy of the alter table command.

Mongo…not so much…

<BEGIN_UNRELATED_SIDE_RANT>

The Mongo documentation is normally the first place most of us go when we’re looking for help in using our favorite noSQL database.

Why?

Well…because that’s usually where Google directs us to go and also because there just isn’t a whole lot of documentation out there on the subject to begin with.

The mongo (10gen) documentation is pretty good.  It’s not, however, excellent.  And I can articulate the reason why.

It’s pretty easy to identify documentation written by engineers as opposed to documentation written by everyone else (on the planet).  And not because of technical content or the (ab)use of really big and impressive-sounding jargon.

No – it’s because most engineering-authored documents are written using a solution-based voice instead of a problem-based voice.

Think about it:  when I have to go to the man-page for help, it’s because I have a problem.  If I had a solution, I would be writing a blog post.    But since I have a problem, I need the man-pages, online docs, whatever, to help me figure-out a solution.

Engineering documents are written from a solution perspective:  the document assumes you possess some bit of arcane lore (which is probably just exactly that little bit of lore that you’re missing which has caused your trip to the documentation vault) and everything that is explained within the document all hinges on this piece of knowledge which the author, albeit with the finest of intentions, assumes is already firmly in your mental possession.

And that’s why I usually don’t like 10gen’s documentation.  But, like I said earlier, it’s the only game in (Google)town.

<END_UNRELATED_SIDE_RANT>

In mongo, to change the name of a column within a collection, you first have to be on a release of mongodb 1.7.2 or later.  Since most of us bleeding-edge, early-adopter types are all 2.x versioned, this shouldn’t be an issue.

This page from 10Gen is the update page and, within, talked about the $rename modifier to the update command.  What the section doesn’t say, because it’s assuming you’re wanting to update records and not schema, is how to apply a change to all of the records in your collection.

In my case, I have a column-name which I fat-fingered the name right out it’s camel-case:  CountryID instead of countryID.  (And, yes, OCD-peeps, I know that it’s not strictly camelCase, thank-you!)  I want to spin through all 3.7 million rows in my collection and rename this column…

> db.geodata_geo.update( {} , { $rename : { 'CountryID' : 'countryID' }}, true, true );

So what we have here is the update command to the collection (geodata_geo) and four parameters:

  1. {} — the empty set (this is what’s missing from the 10gen doc) implying to do whatever to each record in the collection
  2. $rename — the modifier to the update command which, in this case: replace ‘CountryID’ with ‘countryID’
  3. false — indicates to allow upserts if the record does not exist
  4. true — multi option:  means to apply command to all records since, by default, the update() quits after updating the first record

And I run this command and mongo goes off (whirr…whirr … I have two-node replication…) and renames the column in my collection!

What it didn’t do was update my index. 

So, after my column-renaming completed, I needed to drop the index(es) that had ‘CountryID’ as members and re-index the collection to reflect the new column name.

Executing getIndexes() confirmed that my mongo world was back in it’s correct orbit and life, once again, was good.

Page optimized by WP Minify WordPress Plugin

Our weather forecast is from Wunderground for WordPress