README.md in couchrest_model-1.1.0.beta2 vs README.md in couchrest_model-1.1.0.beta3

@@ -9,10 +9,18 @@
 If your project is still running Rails 2.3, you'll have to continue using ExtendedDocument as 
 it is not possible to load ActiveModel into programs that do not use ActiveSupport 3.0.
 
 CouchRest Model is only properly tested on CouchDB version 1.0 or newer.
 
+*WARNING:* As of April 2011 and the release of version 1.1.0, the default model type key is 'model' instead of 'couchrest-type'. Simply updating your project will not work unless you migrate your data or set the configuration option in your initializers:
+
+    CouchRest::Model::Base.configure do |config|
+      config.model_type_key = 'couchrest-type'
+    end
+
+This is because CouchRest Model's are not couchrest specific and may be used in any other system such as a Javascript library, the model type should reflect this.
+
 ## Install
 
 ### Gem
 
     $ sudo gem install couchrest_model
@@ -55,10 +63,11 @@
 * [memories](http://github.com/moonmaster9000/memories) - object versioning using attachments (Matt Parker)
 * [couch_publish](http://github.com/moonmaster9000/couch_publish) - versioned state machine for draft and published documents (Matt Parker)
 * [couch_photo](http://github.com/moonmaster9000/couch_photo) - attach images to documents with variations (Matt Parker)
 * [copycouch](http://github.com/moonmaster9000/copycouch) - single document replication on documents (Matt Parker)
 * [recloner](https://github.com/moonmaster9000/recloner) - clone documents easily (Matt Parker)
+* [couchrest_localised_properties](https://github.com/samlown/couchrest_localised_properties) - Transparent support for localised properties (Sam Lown)
 
 If you have an extension that you'd us to add to this list, please get in touch!
 			   
 ## General Usage 
 
@@ -146,11 +155,11 @@
       property :awake, TrueClass, :default => true
     end
 
     @cat.awake?   # true
 
-Adding the +:default+ option will ensure the attribute always has a value.
+Adding the `:default` option will ensure the attribute always has a value.
 
 A read-only property will only have a getter method, and its value is set when the document
 is read from the database. You can however update a read-only attribute using the `write_attribute` method:
 
     class Cat < CouchRest::Model::Base
@@ -376,11 +385,48 @@
     @posts = Post.by_title.page(params[:page]).per(10)
     
     # In your view, with the kaminari gem loaded:
     paginate @posts
 
+### Design Documents and Views
 
+Views must be defined in a Design Document for CouchDB to be able to perform searches. Each model therefore must have its own Design Document. Deciding when to update the model's design doc is a difficult issue, as in production you don't want to be constantly checking for updates and in development maximum flexability is important. CouchRest Model solves this issue by providing the `auto_update_design_doc` configuration option and is true by default.
+
+Each time a view or other design method is requested a quick GET for the design will be sent to ensure it is up to date with the latest changes. Results are cached in the current thread for the complete design document's URL, including the database, to try and limit requests. This should be fine for most projects, but dealing with multiple sub-databases may require a different strategy.
+
+Setting the option to false will require a manual update of each model's design doc whenever you know a change has happened. This will be useful in cases when you do not want CouchRest Model to interfere with the views already store in the CouchRest database, or you'd like to deploy your own update strategy. Here's an example of a module that will update all submodules:
+
+    module CouchRestMigration
+      def self.update_design_docs
+        CouchRest::Model::Base.subclasses.each{|klass| klass.save_design_doc! if klass.respond_to?(:save_design_doc!)}
+      end
+    end
+
+    # Running this from your applications initializers would be a good idea,
+    # for example in Rail's application.rb or environments/production.rb:
+    config.after_initialize do
+      CouchRestMigration.update_design_docs
+    end
+
+If you're dealing with multiple databases, using proxied models, or databases that are created on-the-fly, a more sophisticated approach might be required:
+
+    module CouchRestMigration
+      def self.update_all_design_docs
+        update_design_docs(COUCHREST_DATABASE)
+        Company.all.each do |company|
+          update_design_docs(company.proxy_database)
+        end
+      end
+      def self.update_design_docs(db)
+        CouchRest::Model::Base.subclasses.each{|klass| klass.save_design_doc!(db) if klass.respond_to?(:save_design_doc!}
+      end
+    end
+
+    # Command to run after a capistrano migration:
+    $ rails runner "CouchRestMigratin.update_all_design_docs"
+
+
 ## Assocations
 
 Two types at the moment:
 
     belongs_to :person
@@ -544,11 +590,11 @@
 
 ## Configuration
 
 CouchRest Model supports a few configuration options. These can be set either for the whole Model code
 base or for a specific model of your chosing. To configure globally, provide something similar to the 
-following in your projects loading code:
+following in your projects initializers or environments:
 
     CouchRest::Model::Base.configure do |config|
       config.mass_assign_any_attribute = true
       config.model_type_key = 'couchrest-type'
     end
@@ -560,10 +606,11 @@
    end
 
 Options currently avilable are:
 
  * `mass_assign_any_attribute` - false by default, when true any attribute may be updated via the update_attributes or attributes= methods.
- * `model_type_key` - 'couchrest-type' by default, is the name of property that holds the class name of each CouchRest Model.
+ * `model_type_key` - 'model' by default, is the name of property that holds the class name of each CouchRest Model.
+ * `auto_update_design_doc` - true by default, every time a view is requested and this option is true, a quick check will be performed to ensure the model's design document is up to date. When disabled, you're design documents will never be updated automatically and you'll need to perform updates manually. Results are cached on a per-database and per-design basis to help lower the number of requests. See the View section for more details.
 
 
 ## Notable Issues
 
 None at the moment...