mongo 1.7.1 → 1.8.0

data/docs/READ_PREFERENCE.md

@@ -1,99 +0,0 @@
-# Read Preference in Ruby
-
-## About Read Preference
-
-Read preferences determine the candidate replica set members to which a query or command can be sent. They consist of a *mode* specified as a symbol and an array of hashes known as *tag_sets*.
-
-Read preference mode is configured by providing the read option to a connection, database, collection, or cursor.
-
-    @collection.find({:doc => 'foo'}, :read => :primary)    # read from primary only
-    @collection.find({:doc => 'foo'}, :read => :secondary)  # read from secondaries only
-
-Used in conjunction with tag_sets:
-
-    @collection.find({:name => 'foo'}, :read => :secondary_preferred, :tag_sets => [{:continent => 'USA'}])
-
-*Please Note*: Behavior of some read preference modes have changed in version 1.7.0:
-
-* `:secondary_preferred` mode is now used to prefer reads from secondary members (before this was the behavior of `:secondary`).
-* `:secondary_only` mode (which only allowed reads from secondaries) is now called `:secondary`.
-
-## Read preference inheritance
-
-The Ruby driver allows you to set read preference on each of four levels: the connection, database, collection, and cursor (or read operation).
-Objects will inherit the default read preference from their parents. Thus, if you set a read preference of `{:read => :secondary}` when creating
-a new connection, then all databases and collections created from that connection will inherit the same setting. See this code example:
-
-    @con = Mongo::ReplSetConnection.new(['localhost:27017','localhost:27018'], :read => :secondary)
-    @db  = @con['test']
-    @collection = @db['foo']
-    @collection.find({:name => 'foo'})
-
-    @collection.find({:name => 'bar'}, :read => :primary)
-
-Here, the first call to Collection#find will use the inherited read preference, `{:read => :secondary}`. But the second call
-to Collection#find overrides this setting by setting the preference to `:primary`.
-
-You can examine the read preference on any object by calling its `read_preference` method:
-
-    @con.read_preference
-    @db.read_preference
-    @collection.read_preference
-
-## Modes
-
-You can using the `:read` option to specify a query's read preference mode. There are five possible options.
-
-### :primary
-
-With primary, all read operations from the client will use the primary member only. This is the default read preference.
-
-If the primary is unavailable, all operations with this preference produce an error or throw an exception. Primary read preference modes are not compatible with read preferences modes that use tag sets If you specify a tag set with primary, the driver will produce an error.
-
-### :primary_preferred
-
-With the primaryPreferred read preference mode, operations will read from the primary member of the set in most situations. However, if the primary is unavailable, as is the case during failover situations, then these read operations can read from secondary members.
-
-When the read preference includes a tag set, the client will first read from the primary, if it is available, and then from secondaries that match the specified tags. If there are no secondaries with tags that match the specified tags, this read operation will produce an error.
-
-### :secondary
-
-With the secondary read preference mode, operations will read from the secondary member of the set if available. However, if there are no secondaries available, then these operations will produce an error or exception.
-
-Most sets have at least one secondary, but there are situations where there may not be an available secondary. For example, a set with a primary, a secondary, and an arbiter may not have any secondaries if a member is ever in recovering mode.
-
-When the read preference includes a tag set, the client will attempt to find a secondary members that match the specified tag set and directs reads to a random secondary from among the nearest group. If there are no secondaries with tags that match the specified tag set, this read operation will produce an error.
-
-### :secondary_preferred
-
-With the secondaryPreferred, operations will read from secondary members, but in situations where the set only has a primary instance, the read operation will use the set’s primary.
-
-When secondaryPreferred reads from a secondary and the read preference includes a tag set, the client will attempt to find a secondary members that match the specified tag set and directs reads to a random secondary from among the nearest group. If there are no secondaries with tags that match the specified tag set, this read operation will produce an error.
-
-### :nearest
-
-With the nearest, the driver will read from the nearest member of the set according to the member selection process nearest read operations will not have any consideration for the type of the set member. Reads in nearest mode may read from both primaries and secondaries.
-
-Set this mode when you want minimize the effect of network latency on read operations without preference for current or stale data.
-
-If you specify a tag set, the client will attempt to find a secondary members that match the specified tag set and directs reads to a random secondary from among the nearest group.
-
-## Tag Sets
-
-Tag sets can be used in for data center awareness by filtering secondary read operations. Primary reads occur independent of any tags.
-
-A member matches a tag set if its tags match all the tags in the set. For example, a member tagged "{ dc: 'ny', rack: 2, size: 'large' }" matches the tag set "{ dc: 'ny', rack: 2 }". A member's extra tags don't affect whether it's a match.
-
-Here is an example of a query which sends read operations to members in rack 2.
-
-    @collection.find({:name => 'foo'}, :read => :secondary_preferred, :tag_sets => [{:rack => '2'}])
-
-Tag set keys may be symbols or strings. Tag set values should be specified using strings. The `to_s` method will be called on any values provided in the tag set.
-
-Tag sets are used in conjunction with read preference mode. In this example, because we specified a mode of secondary_preferred, if no secondaries can be found that match the tag_set `{:rack => '2'}` then the primary will be used for the query.
-
-If only one tag set is provided, the set can be passed as a single hash parameter iteself without the enclosing array.
-
-    @collection.find({:name => 'foo'}, :read => :secondary_preferred, :tag_sets => {:rack => '2'})
-
-Specifiying tag_sets for mode `:primary` is considered an error and will raise a MongoArgumentError as tag_sets do not affect selection of primary members and only primary members can be selected in that particular mode.

data/docs/RELEASES.md

@@ -1,54 +0,0 @@
-# MongoDB Ruby Driver Release Plan
-
-This is a description of a formalized release plan that will take effect
-with version 1.3.0.
-
-## Semantic versioning
-
-The most significant difference is that releases will now adhere to the conventions of
-[semantic versioning](http://semver.org). In particular, we will strictly abide by the
-following release rules:
-
-1. Patch versions of the driver (Z in x.y.Z) will be released only when backward-compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
-
-2. Minor versions (Y in x.Y.z) will be released if new, backward-compatible functionality is introduced to the public API.
-
-3. Major versions (X in X.y.z) will be incremented if any backward-incompatible changes are introduced to the public API.
-
-This policy will clearly indicate to users when an upgrade may affect their code. As a side effect, version numbers will climb more quickly than before.
-
-
-## Release checklist
-
-Before each relese to Rubygems.org, the following steps will be taken:
-
-1. All driver tests will be run on Linux, OS X, and Windows via continuous integration system.
-
-2. Update the HISTORY file and document all significant commits.
-
-3. Update the version in lib/bson.rb, lib/mongo/version.rb, and ext/cbson/version.h.
-
-4. Commit: "RELEASE [VERSION]"
-
-5. git tag [version]
-
-6. Build gems. Ensure that they have the correct versions.
-
-7. Push tags and commit to GitHub (git push origin master, git push --tags).
-
-8. Build and push docs. (git: mongodb/apidocs)
-
-9. Push gems to Rubygems.org.
-
-10. Test that the gem is downloadable from Rubygems.org.
-
-11. Close out release in JIRA.
-
-12. Annouce release on mongodb-user and mongodb-dev.
-
-## Rake Deploy Tasks
-1. rake deploy:change_version[x.x.x]
-2. rake deploy:git_prepare
-3. rake deploy:git_push
-4. rake deploy:gem_build
-5. rake deploy:gem_push

data/docs/REPLICA_SETS.md

@@ -1,113 +0,0 @@
-# Replica Sets in Ruby
-
-Here follow a few considerations for those using the MongoDB Ruby driver with [replica sets](http://www.mongodb.org/display/DOCS/Replica+Sets).
-
-### Setup
-
-First, make sure that you've configured and initialized a replica set.
-
-Use `ReplSetConnection.new` to connect to a replica set. This method, which accepts a variable number of arugments,
-takes a list of seed nodes followed by any connection options. You'll want to specify at least two seed nodes. This gives
-the driver more chances to connect in the event that any one seed node is offline. Once the driver connects, it will
-cache the replica set topology as reported by the given seed node and use that information if a failover is later required.
-
-    @connection = ReplSetConnection.new(['n1.mydb.net:27017', 'n2.mydb.net:27017', 'n3.mydb.net:27017'])
-
-### Read slaves
-
-If you want to read from a secondary node, you can pass :read => :secondary to ReplSetConnection#new.
-
-    @connection = ReplSetConnection.new(['n1.mydb.net:27017', 'n2.mydb.net:27017', 'n3.mydb.net:27017'],
-                  :read => :secondary)
-
-A random secondary will be chosen to be read from. In a typical multi-process Ruby application, you'll have a good distribution of reads across secondary nodes.
-
-### Connection Failures
-
-Imagine that either the master node or one of the read nodes goes offline. How will the driver respond?
-
-If any read operation fails, the driver will raise a *ConnectionFailure* exception. It then becomes the client's responsibility to decide how to handle this.
-
-If the client decides to retry, it's not guaranteed that another member of the replica set will have been promoted to master right away, so it's still possible that the driver will raise another *ConnectionFailure*. However, once a member has been promoted to master, typically within a few seconds, subsequent operations will succeed. *Note that this does not prevent
-exception in the event of a primary failover.*
-
-The driver will essentially cycle through all known seed addresses until a node identifies itself as master.
-
-### Refresh mode
-
-You can now specify a refresh mode and refresh interval for a replica set connection. This will help to ensure that
-changes to a replica set's configuration are quickly reflected on the driver side. In particular, if you change
-the state of any secondary node, the automated refresh will ensure that this state is recorded on the client side.
-
-There are two secenarios in which refresh is helpful and does not raise exceptions:
-
-1. You add a new secondary node to an existing replica set
-2. You remove an unused secondary from an existing replica set
-
-If using MongoDB earlier than 2.0 any changes to replica set state will raise exceptions therefore refresh mode will not be useful.
-
-If you add a secondary that responds to pings much faster than the existing nodes, then the new secondary will
-be used for reads if :read_preference is :secondary or :secondary_only
-
-Refresh mode is disabled by default.
-
-However, if you expect to make live changes to your secondaries, and you want this to be reflected without
-having to manually restart your app server, then you should enable it. You can enable this mode
-synchronously, which will refresh the replica set data in a synchronous fashion (which may
-ocassionally slow down your queries):
-
-    @connection = ReplSetConnection.new(['n1.mydb.net:27017'], :refresh_mode => :sync)
-
-If you want to change the default refresh interval of 90 seconds, you can do so like this:
-
-    @connection = ReplSetConnection.new(['n1.mydb.net:27017'], :refresh_mode => :sync,
-        :refresh_interval => 60)
-
-Do not set this value to anything lower than 30, or you may start to experience performance issues.
-
-You can also disable refresh mode altogether:
-
-    @connection = ReplSetConnection.new(['n1.mydb.net:27017'], :refresh_mode => false)
-
-And you can call `refresh` manually on any replica set connection:
-
-    @connection.refresh
-
-### Recovery
-
-Driver users may wish to wrap their database calls with failure recovery code. Here's one possibility, which will attempt to connection
-every half second and time out after thirty seconds.
-
-    # Ensure retry upon failure
-    def rescue_connection_failure(max_retries=60)
-      retries = 0
-      begin
-        yield
-      rescue Mongo::ConnectionFailure => ex
-        retries += 1
-        raise ex if retries > max_retries
-        sleep(0.5)
-        retry
-      end
-    end
-
-    # Wrapping a call to #count()
-    rescue_connection_failure do
-      @db.collection('users').count()
-    end
-
-Of course, the proper way to handle connection failures will always depend on the individual application. We encourage object-mapper and application developers to publish any promising results.
-
-### Testing
-
-The Ruby driver (>= 1.1.5) includes unit tests for verifying replica set behavior. They reside in *tests/replica_sets*. You can run them as a group with the following rake task:
-
-    rake test:rs
-
-The suite will set up a five-node replica set by itself and ensure that driver behaves correctly even in the face
-of individual node failures. Note that the `mongod` executable must be in the search path for this to work.
-
-### Further Reading
-
-* [Replica Sets](http://www.mongodb.org/display/DOCS/Replica+Set+Configuration)
-* [Replics Set Configuration](http://www.mongodb.org/display/DOCS/Replica+Set+Configuration)

data/docs/TAILABLE_CURSORS.md

@@ -1,51 +0,0 @@
-# Tailable cursors in Ruby
-
-Tailable cursors are cursors that remain open even after they've returned
-a final result. This way, if more documents are added to a collection (i.e.,
-to the cursor's result set), then you can continue to call `Cursor#next` to
-retrieve those results. Here's a complete test case that demonstrates the use
-of tailable cursors.
-
-Note that tailable cursors are for capped collections only.
-
-      require 'mongo'
-      require 'test/unit'
-
-      class TestTailable < Test::Unit::TestCase
-        include Mongo
-
-        def test_tailable
-
-          # Create a connection and capped collection.
-          @con = Connection.new
-          @db  = @con['test']
-          @db.drop_collection('log')
-          @capped = @db.create_collection('log', :capped => true, :size => 1024)
-
-          # Insert 10 documents.
-          10.times do |n|
-            @capped.insert({:n => n})
-          end
-
-          # Create a tailable cursor that iterates the collection in natural order
-          @tail = Cursor.new(@capped, :tailable => true, :order => [['$natural', 1]])
-
-          # Call Cursor#next 10 times. Each call returns a document.
-          10.times do
-            assert @tail.next
-          end
-
-          # But the 11th time, the cursor returns nothing.
-          assert_nil @tail.next
-
-          # Add a document to the capped collection.
-          @capped.insert({:n => 100})
-
-          # Now call Cursor#next again. This will return the just-inserted result.
-          assert @tail.next
-
-          # Close the cursor.
-          @tail.close
-        end
-
-      end

data/docs/TUTORIAL.md

@@ -1,356 +0,0 @@
-# MongoDB Ruby Driver Tutorial
-
-This tutorial gives many common examples of using MongoDB with the Ruby driver. If you're looking for information on data modeling, see [MongoDB Data Modeling and Rails](http://www.mongodb.org/display/DOCS/MongoDB+Data+Modeling+and+Rails). Links to the various object mappers are listed on our [object mappers page](http://www.mongodb.org/display/DOCS/Object+Mappers+for+Ruby+and+MongoDB).
-
-Interested in GridFS? See [GridFS in Ruby](file.GridFS.html).
-
-As always, the [latest source for the Ruby driver](http://github.com/mongodb/mongo-ruby-driver) can be found on [github](http://github.com/mongodb/mongo-ruby-driver/).
-
-## Installation
-
-The mongo-ruby-driver gem is served through Rubygems.org. To install, make sure you have the latest version of rubygems.
-
-    gem update --system
-
-Next, install the mongo rubygem:
-
-    gem install mongo
-
-The required `bson` gem will be installed automatically.
-
-For optimum performance, install the bson\_ext gem:
-
-    gem install bson_ext
-
-After installing, you may want to look at the [examples](http://github.com/mongodb/mongo-ruby-driver/tree/master/examples) directory included in the source distribution. These examples walk through some of the basics of using the Ruby driver.
-
-## Getting started
-
-Note that the output in the following has been updated to Ruby 1.9, so if you are using Ruby 1.8, you will see some minor differences.  To follow this tutorial interactively, at the command line, run the Interactive Ruby Shell.
-
-    irb
-
-As you execute commands, irb will output the result using the `inspect` method.  If you are editing and running a script for this tutorial, you can view output using the `puts` or `p` methods.
-
-### Using the gem
-
-Use the `mongo` gem via the `require` kernel method.
-
-    require 'rubygems'  # not necessary for Ruby 1.9
-    require 'mongo'
-
-### Making a Connection
-
-An `Mongo::Connection` instance represents a connection to MongoDB.  You can optionally specify the MongoDB server address and port when connecting. The following example shows three ways to connect to the local machine:
-
-    connection = Mongo::Connection.new # (optional host/port args)
-    connection = Mongo::Connection.new("localhost")
-    connection = Mongo::Connection.new("localhost", 27017)
-
-### Listing All Databases
-
-    connection.database_names
-    connection.database_info.each { |info| puts info.inspect }
-
-The `database_info` method returns a hash mapping database names to the size of the database in bytes.
-
-## Using a Database
-
-You use a Connection instance to obtain an Mongo::DB instance, which represents a named database. The database doesn't have to exist - if it doesn't, MongoDB will create it for you. The following examples use the database "mydb":
-
-    db = connection.db("mydb")
-    db = Mongo::Connection.new.db("mydb")
-
-At this point, the `db` object will be a connection to a MongoDB server for the specified database. Each DB instance uses a separate socket connection to the server.
-
-If you're trying to connect to a replica set, see [Replica Sets in Ruby](http://www.mongodb.org/display/DOCS/Replica+Sets+in+Ruby).
-
-### Authentication
-
-MongoDB can be run in a secure mode where access to databases is controlled through name and password authentication.  When run in this mode, any client application must provide a name and password before doing any operations.  In the Ruby driver, you simply do the following with the connected mongo object:
-
-    auth = db.authenticate(my_user_name, my_password)
-
-If the name and password are valid for the database, `auth` will be `true`.  Otherwise, it will be `false`.  You should look at the MongoDB log for further information if available.
-
-## Using a Collection
-
-You can get a collection to use using the `collection` method:
-
-    coll = db.collection("testCollection")
-
-This is aliased to the \[\] method:
-
-    coll = db["testCollection"]
-
-Once you have this collection object, you can now do create, read, update, and delete (CRUD) functions on persistent storage.
-
-### Creating Documents with `insert`
-
-Once you have the collection object, you can create or `insert` documents into the collection.  For example, lets make a little document that in JSON would be represented as
-
-      {
-         "name" : "MongoDB",
-         "type" : "database",
-         "count" : 1,
-         "info" : {
-                     x : 203,
-                     y : 102
-                   }
-      }
-
-Notice that the above has an "inner" document embedded within it.  To do this, we can use a Hash or the driver's OrderedHash (which preserves key order) to create the document (including the inner document), and then just simply insert it into the collection using the `insert` method.
-
-    doc = {"name" => "MongoDB", "type" => "database", "count" => 1, "info" => {"x" => 203, "y" => '102'}}
-    id = coll.insert(doc)
-
-We have saved the `id` for future use below.  Now the collection has been created and you can list it.
-
-#### Getting a List Of Collections
-
-Each database has zero or more collections.  You can retrieve a list of them from the db (and print out any that are there):
-
-	db.collection_names
-
-You should see
-
-	\["testCollection", "system.indexes"\]
-
-#### Adding Multiple Documents
-
-To demonstrate some more interesting queries, let's add multiple simple documents to the collection.  These documents will have the following form:
-
-	{
-	    "i" : value
-	}
-
-Here's how to insert them:
-
-	100.times { |i| coll.insert("i" => i) }
-
-Notice that we can insert documents of different "shapes" into the same collection. These records are in the same collection as the complex record we inserted above.  This aspect is what we mean when we say that MongoDB is "schema-free".
-
-### Reading Documents with `find_one` and `find`
-
-#### Reading the First Document in a Collection using `find_one`
-
-To retrieve the document that we inserted, we can do a simple `find_one` method to get the first document in the collection.  This method returns a single document directly.
-
-	coll.find_one
-
-and you should something like:
-
-	{"_id"=>BSON::ObjectId('4f7b1ea6e4d30b35c9000001'), "name"=>"MongoDB", "type"=>"database", "count"=>1, "info"=>{"x"=>203, "y"=>"102"}}
-
-Note the `_id` element has been added automatically by MongoDB to your document.
-
-#### Reading All of the Documents with a Cursor using `find`
-
-To get all the documents from the collection, we use the `find` method. `find` returns a `Cursor` object, which allows us to iterate over the set of documents that matches our query.  The Ruby driver's Cursor implemented Enumerable, which allows us to use `Enumerable#each`, `Enumerable#map}, etc. For instance:
-
-	coll.find.each { |row| puts row.inspect }
-
-and that should print all 101 documents in the collection.  You can take advantage of `Enumerable#to_a`.
-
-    puts coll.find.to_a
-
-Important note - using `to_a` pulls all of the full result set into memory and is inefficient if you can process by each individual document.  To process with more memory efficiency, use the `each` method with a code block for the cursor.
-
-#### Specific Queries
-
-We can create a _query_ hash to pass to the `find` method to get a subset of the documents in our collection.  To check that our update worked, find the document by id:
-
-    coll.find("_id" => id).to_a
-
-If we wanted to find the document for which the value of the "i" field is 71, we would do the following:
-
-    coll.find("i" => 71).to_a
-
-and it should just print just one document:
-
-    {"_id"=>BSON::ObjectId('4f7b20b4e4d30b35c9000049'), "i"=>71}
-
-#### Sorting Documents in a Collection
-
-To sort documents, simply use the `sort` method. The method can either take a key or an array of [key, direction] pairs to sort by.
-
-Direction defaults to ascending order but can be specified as Mongo::ASCENDING, :ascending, or :asc whereas descending order can be specified with Mongo::DESCENDING, :descending, or :desc.
-
-    # Sort in ascending order by :i
-    coll.find.sort(:i)
-
-    # Sort in descending order by :i
-    coll.find.sort(:i => :desc)
-
-#### Counting Documents in a Collection
-
-Now that we've inserted 101 documents (the 100 we did in the loop, plus the first one), we can check to see if we have them all using the `count` method.
-
-    coll.count
-
-and it should print `101`.
-
-#### Getting a Set of Documents With a Query
-
-We can use the query to get a set of documents from our collection.  For example, if we wanted to get all documents where "i" > 50, we could write:
-
-    puts coll.find("i" => {"$gt" => 50}).to_a
-
-which should print the documents where i > 50.  We could also get a range, say   20 < i <= 30:
-
-    puts coll.find("i" => {"$gt" => 20, "$lte" => 30}).to_a
-
-#### Selecting a Subset of Fields for a Query
-
-Use the `:fields` option to specify fields to return.
-
-    puts coll.find("_id" => id, :fields => ["name", "type"]).to_a
-
-#### Querying with Regular Expressions
-
-Regular expressions can be used to query MongoDB. To find all names that begin with 'M':
-
-    puts coll.find({"name" => /^M/}).to_a
-
-You can also construct a regular expression dynamically. To match a given search string:
-
-    params = {'search' => 'DB'}
-    search_string = params['search']
-
-    # Constructor syntax
-    puts coll.find({"name" => Regexp.new(search_string)}).to_a
-
-    # Literal syntax
-    puts coll.find({"name" => /#{search_string}/}).to_a
-
-Although MongoDB isn't vulnerable to anything like SQL-injection, it may be worth checking the search string for anything malicious.
-
-### Updating Documents with `update`
-
-We can update the previous document using the `update` method. There are a couple ways to update a document. We can rewrite it:
-
-    doc["name"] = "MongoDB Ruby"
-    coll.update({"_id" => id}, doc)
-
-Or we can use an atomic operator to change a single value:
-
-    coll.update({"_id" => id}, {"$set" => {"name" => "MongoDB Ruby"}})
-
-Verify the update.
-
-    puts coll.find("_id" => id).to_a
-
-Read [more about updating documents|Updating].
-
-### Deleting Documents with `remove`
-
-Use the `remove` method to delete documents.
-
-    coll.count
-    coll.remove("i" => 71)
-    coll.count
-    puts coll.find("i" => 71).to_a
-
-The above shows that the count has been reduced and that the document can no longer be found.
-
-Without arguments, the `remove` method deletes all documents.
-
-    coll.remove
-    coll.count
-
-Please program carefully.
-
-## Indexing
-
-### Creating An Index
-
-MongoDB supports indexes, and they are very easy to add on a collection.  To create an index, you specify an index name and an array of field names to be indexed, or a single field name. The following creates an ascending index on the "i" field:
-
-    # create_index assumes ascending order; see method docs
-    # for details
-    coll.create_index("i")
-To specify complex indexes or a descending index you need to use a slightly more complex syntax - the index specifier must be an Array of [field name, direction] pairs. Directions should be specified as Mongo::ASCENDING or Mongo::DESCENDING:
-
-    # Explicit "ascending"
-    coll.create_index([["i", Mongo::ASCENDING]])
-
-Use the `explain` method on the cursor to show how MongoDB will run the query.
-
-    coll.find("_id" => id).explain
-    coll.find("i" => 71).explain
-    coll.find("type" => "database").explain
-
-The above shows that the query by `_id` and `i` will use faster indexed BtreeCursor, while the query by `type` will use a slower BasicCursor.
-
-### Getting a List of Indexes on a Collection
-
-You can get a list of the indexes on a collection.
-
-    coll.index_information
-
-### Creating and Querying on a Geospatial Index
-
-First, create the index on a field containing long-lat values:
-
-    people.create_index([["loc", Mongo::GEO2D]])
-
-Then get a list of the twenty locations nearest to the point 50, 50:
-
-    people.find({"loc" => {"$near" => [50, 50]}}, {:limit => 20}).each do |p|
-      puts p.inspect
-    end
-
-## Dropping
-
-### Drop an Index
-
-To drop a secondary index, use the `drop_index` method on the collection.
-
-    coll.drop_index("i_1")
-    coll.index_information
-
-The dropped index is no longer listed.
-
-### Drop All Indexes
-
-To drop all secondary indexes, use the `drop_indexes` method on the collection.
-
-    coll.drop_indexes
-    coll.index_information
-
-Only the primary index "_id_" is listed.
-
-### Drop a Collection
-
-To drop a collection, use the `drop` method on the collection.
-
-    coll.drop
-    db.collection_names
-
-The dropped collection is no longer listed.  The `drop_collection` method can be used on the database as an alternative.
-
-    db.drop_collection("testCollection")
-
-### Drop a Database
-
-To drop a database, use the `drop_database` method on the connection.
-
-    connection.drop_database("mydb")
-    connection.database_names
-
-The dropped database is no longer listed.
-
-## Database Administration
-
-A database can have one of three profiling levels: off (:off), slow queries only (:slow_only), or all (:all). To see the database level:
-
-    puts db.profiling_level   # => off (the symbol :off printed as a string)
-    db.profiling_level = :slow_only
-
-Validating a collection will return an interesting hash if all is well or raise an exception if there is a problem.
-    p db.validate_collection('coll_name')
-
-## See Also
-
-* [MongoDB Koans](http://github.com/chicagoruby/MongoDB_Koans) A path to MongoDB enlightenment via the Ruby driver.
-* [MongoDB Manual](http://www.mongodb.org/display/DOCS/Developer+Zone)