A DelegateCollection wraps a local collection and remote collection in one object that implements the Collection interface.
-
All reads are first done on the local collection, then supplemented by a read on the remote collection, if necessary.
-
All writes occur in the local collection. The remote collection is treated as read-only.
This was inspired by things I’ve been told about Goldman Sachs’ proprietary object database. You can point one database at another remote database, and it will function in this manner.
The classic use case is debugging a production problem, or developing while using production data. ¶ ↑
The annoying ways
-
Generate data that mimics production
-
Get a production dump and load it locally
-
“Test” in production while walking on eggshells to make sure not to break anything
The easy way
-
Have your local app use a delegating collection that points at the production db.
-
Your app will be using live production data, but all writes occur locally.
-
As writes occur, the app will get your newly written data for those documents.
-
Your app can be oblivious to the delegation and function normally, and you can modify data without fear.
Just create a DelegatingDatabase and pass to your application, wherever you would normally supply a database
db = Mongo::DelegatingDatabase.new(:local => Mongo::Connection.new.db('db-name'), :remote => Mongo::Connection.new('remote ip').db('db-name'))
Later, anywhere collections are retrieved in your app
# This returns an instance of Mongo::DelegatingCollection coll = db.collection('some-collection-name')
-
Fork the project.
-
Make your feature addition or bug fix.
-
Add tests for it. This is important so I don’t break it in a future version unintentionally.
-
Commit, do not mess with rakefile, version, or history. (if you want to have your own version, that is fine but
bump version in a commit by itself I can ignore when I pull)
-
Send me a pull request. Bonus points for topic branches.
Copyright © 2010 Mike Harris. See LICENSE for details.