couchrest_model 1.1.0.beta4 → 1.1.0.beta5

Sign up to get free protection for your applications and to get access to all the features.
data/.gitignore CHANGED
@@ -8,3 +8,4 @@ couchdb.std*
8
8
  *.*~
9
9
  Gemfile.lock
10
10
  spec.out
11
+ *.gem
data/README.md CHANGED
@@ -3,6 +3,16 @@
3
3
  CouchRest Models adds additional functionality to the standard CouchRest Document class such as
4
4
  setting properties, callbacks, typecasting, and validations.
5
5
 
6
+ ## Documentation
7
+
8
+ Please visit the documentation project at [http://www.couchrest.info](http://www.couchrest.info). You're [contributions](https://github.com/couchrest/couchrest.github.com) to the documentation would be greatly appreciated!
9
+
10
+ General API: [http://rdoc.info/projects/couchrest/couchrest_model](http://rdoc.info/projects/couchrest/couchrest_model)
11
+
12
+ See the [update history](https://github.com/couchrest/couchrest_model/blob/master/history.md) for an up to date list of all the changes we've been working on recently.
13
+
14
+ ## Notes
15
+
6
16
  Originally called ExtendedDocument, the new Model structure uses ActiveModel, part of Rails 3,
7
17
  for validations and callbacks.
8
18
 
@@ -11,13 +21,13 @@ it is not possible to load ActiveModel into programs that do not use ActiveSuppo
11
21
 
12
22
  CouchRest Model is only properly tested on CouchDB version 1.0 or newer.
13
23
 
14
- *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:
24
+ *WARNING:* As of April 2011 and the release of version 1.1.0, the default model type key is 'type' instead of 'couchrest-type'. Simply updating your project will not work unless you migrate your data or set the configuration option in your initializers:
15
25
 
16
26
  CouchRest::Model::Base.configure do |config|
17
27
  config.model_type_key = 'couchrest-type'
18
28
  end
19
29
 
20
- 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.
30
+ This is because CouchRest Model's are not couchrest specific and may be used in any other systems such as Javascript, the model type should reflect this. Also, we're all used to `type` being a reserved word in ActiveRecord.
21
31
 
22
32
  ## Install
23
33
 
@@ -31,44 +41,39 @@ If you're using bundler, define a line similar to the following in your project'
31
41
 
32
42
  gem 'couchrest_model'
33
43
 
34
- You might also consider using the latest git repository. We try to make sure the current version in git is stable and at the very least all tests should pass.
44
+ ### Configuration
35
45
 
36
- gem 'couchrest_model', :git => 'git://github.com/couchrest/couchrest_model.git'
46
+ CouchRest Model is configured to work out the box with no configuration as long as your CouchDB instance is running on the default port (5984) on localhost. The default name of the database is either the name of your application as provided by the `Rails.application.class.to_s` call (with /application removed) or just 'couchrest' if none is available.
37
47
 
38
- ### Setup
48
+ The library will try to detect a configuration file at `config/couchdb.yml` from the Rails root or `Dir.pwd`. Here you can configuration your database connection in a Rails-like way:
39
49
 
40
- There is currently no standard way for telling CouchRest Model how it should access your database, this is something we're still working on. For the time being, the easiest way is to set a COUCHDB_DATABASE global variable to an instance of CouchRest Database, and call `use_database COUCHDB_DATABASE` in each model.
50
+ development:
51
+ protocol: 'https'
52
+ host: sample.cloudant.com
53
+ port: 443
54
+ prefix: project
55
+ suffix: test
56
+ username: test
57
+ password: user
41
58
 
42
- TODO: Add an example!
59
+ Note that the name of the database is either just the prefix and suffix combined or the prefix plus any text you specifify using `use_database` method in your models with the suffix on the end.
43
60
 
44
- ### Development
61
+ The example config above for example would use a database called "project_test". Heres an example using the `use_database` call:
45
62
 
46
- CouchRest Model now comes with a Gemfile to help with development. If you want to make changes to the code, download a copy then run:
63
+ class Project < CouchRest::Model::Base
64
+ use_database 'sample'
65
+ end
47
66
 
48
- bundle install
67
+ # The database object would be provided as:
68
+ Project.database #=> "https://test:user@sample.cloudant.com:443/project_sample_test"
49
69
 
50
- That should set everything up for `rake spec` to be run correctly. Update the couchrest_model.gemspec if your alterations
51
- use different gems.
52
70
 
53
71
  ## Generators
54
72
 
55
73
  ### Model
56
74
 
57
- $ rails generate model person --orm=couchrest_model
58
-
59
- ## Useful links and extensions
60
-
61
- Try some of these gems that add extra funcionality to couchrest_model:
75
+ $ rails generate model person --orm=couchrest_model
62
76
 
63
- * [memories](http://github.com/moonmaster9000/memories) - object versioning using attachments (Matt Parker)
64
- * [couch_publish](http://github.com/moonmaster9000/couch_publish) - versioned state machine for draft and published documents (Matt Parker)
65
- * [couch_photo](http://github.com/moonmaster9000/couch_photo) - attach images to documents with variations (Matt Parker)
66
- * [copycouch](http://github.com/moonmaster9000/copycouch) - single document replication on documents (Matt Parker)
67
- * [recloner](https://github.com/moonmaster9000/recloner) - clone documents easily (Matt Parker)
68
- * [couchrest_localised_properties](https://github.com/samlown/couchrest_localised_properties) - Transparent support for localised properties (Sam Lown)
69
-
70
- If you have an extension that you'd us to add to this list, please get in touch!
71
-
72
77
  ## General Usage
73
78
 
74
79
  require 'couchrest_model'
@@ -100,533 +105,22 @@ If you have an extension that you'd us to add to this list, please get in touch!
100
105
  @cat.new? # false
101
106
  @cat.random_text # Raises error!
102
107
 
108
+ ## Development
103
109
 
104
- ## Properties
105
-
106
- A property is the definition of an attribute, it describes what the attribute is called, how it should
107
- be type casted and other options such as the default value. These replace your typical
108
- `add_column` methods found in relational database migrations.
109
-
110
- Attributes with a property definition will have setter and getter methods defined for them. Any other attibute
111
- can be set as if the model were a Hash, this funcionality is inherited from CouchRest Documents.
112
-
113
- Here are a few examples of the way properties are used:
114
-
115
- class Cat < CouchRest::Model::Base
116
- property :name
117
- property :birthday
118
- end
119
-
120
- @cat = Cat.new(:name => 'Felix', :birthday => 2.years.ago)
121
- @cat.name # 'Felix'
122
- @cat.birthday.is_a?(Time) # True!
123
- @cat.save
124
- @cat = Cat.find(@cat.id)
125
- @cat.name # 'Felix'
126
- @cat.birthday.is_a?(Time) # False!
127
-
128
- Properties create getters and setters similar to the following:
129
-
130
- def name
131
- read_attribute('name')
132
- end
133
-
134
- def name=(value)
135
- write_attribute('name', value)
136
- end
137
-
138
- Properties can also have a type which will be used for casting data retrieved from CouchDB when the attribute is set:
139
-
140
- class Cat < CouchRest::Model::Base
141
- property :name, String
142
- property :last_fed_at, Time
143
- end
144
-
145
- @cat = Cat.new(:name => 'Felix', :last_fed_at => 10.minutes.ago)
146
- @cat.last_fed_at.is_a?(Time) # True!
147
- @cat.save
148
- @cat = Cat.find(@cat.id)
149
- @cat.last_fed_at < 20.minutes.ago # True!
150
-
151
-
152
- Boolean or TrueClass types will create a getter with question mark at the end:
153
-
154
- class Cat < CouchRest::Model::Base
155
- property :awake, TrueClass, :default => true
156
- end
157
-
158
- @cat.awake? # true
159
-
160
- Adding the `:default` option will ensure the attribute always has a value.
161
-
162
- A read-only property will only have a getter method, and its value is set when the document
163
- is read from the database. You can however update a read-only attribute using the `write_attribute` method:
164
-
165
- class Cat < CouchRest::Model::Base
166
- property :name, String
167
- property :lives, Integer, :default => 9, :readonly => true
168
-
169
- def fall_off_balcony!
170
- write_attribute(:lives, lives - 1)
171
- save
172
- end
173
- end
174
-
175
- @cat = Cat.new(:name => "Felix")
176
- @cat.fall_off_balcony!
177
- @cat.lives # Now 8!
178
-
179
- Mass assigning attributes is also possible in a similar fashion to ActiveRecord:
180
-
181
- @cat.attributes = { :name => "Felix" }
182
- @cat.save
183
-
184
- Is the same as:
185
-
186
- @cat.update_attributes(:name => "Felix")
187
-
188
- By default, attributes without a property will not be updated via the `#attributes=` method. This provents useless data being passed to database, for example from an HTML form. However, if you would like truely
189
- dynamic attributes, the `mass_assign_any_attribute` configuration option when set to true will
190
- store everything you put into the `Base#attributes=` method.
191
-
192
-
193
- ## Property Arrays
194
-
195
- An attribute may contain an array of data. CouchRest Model handles this, along
196
- with casting, by defining the class of the child attributes inside an Array:
197
-
198
- class Cat < CouchRest::Model::Base
199
- property :name, String
200
- property :nicknames, [String]
201
- end
202
-
203
- By default, the array will be ready to use from the moment the object as been instantiated:
204
-
205
- @cat = Cat.new(:name => 'Fluffy')
206
- @cat.nicknames << 'Buffy'
207
-
208
- @cat.nicknames == ['Buffy']
209
-
210
- When anything other than a string is set as the class of a property, the array will be converted
211
- into special wrapper called a CastedArray. If the child objects respond to the `casted_by` method
212
- (such as those created with CastedModel, below) it will contain a reference to the parent.
213
-
214
- ## Casted Models
215
-
216
- CouchRest Model allows you to take full advantage of CouchDB's ability to store complex
217
- documents and retrieve them using the CastedModel module. Simply include the module in
218
- a Hash (or other model that responds to the [] and []= methods) and set any properties
219
- you'd like to use. For example:
220
-
221
- class CatToy < Hash
222
- include CouchRest::Model::CastedModel
223
-
224
- property :name, String
225
- property :purchased, Date
226
- end
227
-
228
- class Cat < CouchRest::Model::Base
229
- property :name, String
230
- property :toys, [CatToy]
231
- end
232
-
233
- @cat = Cat.new(:name => 'Felix', :toys => [{:name => 'mouse', :purchased => 1.month.ago}])
234
- @cat.toys.first.class == CatToy
235
- @cat.toys.first.name == 'mouse'
236
-
237
- Any hashes sent to the property will automatically be converted:
238
-
239
- @cat.toys << {:name => 'catnip ball'}
240
- @cat.toys.last.is_a?(CatToy) # True!
241
-
242
- To use your own classes they *must* be defined before the parent uses them otherwise
243
- Ruby will bring up a missing constant error. To avoid this, or if you have a really simple array of data
244
- you'd like to model, CouchRest Model supports creating anonymous classes:
245
-
246
- class Cat < CouchRest::Model::Base
247
- property :name, String
248
-
249
- property :toys do
250
- property :name, String
251
- property :rating, Integer
252
- end
253
- end
254
-
255
- @cat = Cat.new(:name => 'Felix', :toys => [{:name => 'mouse', :rating => 3}, {:name => 'catnip ball', :rating => 5}])
256
- @cat.toys.last.rating == 5
257
- @cat.toys.last.name == 'catnip ball'
258
-
259
- Anonymous classes will *only* create arrays of objects. If you're more of the traditional type, a block parameter
260
- can be provided allowing you to use this variable before each method call inside the anonymous class. This is useful
261
- if you need to access variables outside of the block.
262
-
263
- ## Views
264
-
265
- CouchDB views can be quite difficult to get grips with at first as they are quite different from what you'd expect with SQL queries in a normal Relational Database. Checkout some of the [CouchDB documentation on views](http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views) to get to grips with the basics. The key is to remember that CouchDB will only generate indexes from which you can extract consecutive rows of data, filtering other than between two points in a data set is not possible.
266
-
267
- CouchRest Model has great support for views, and since version 1.1.0 we added support for a View objects that make accessing your data even easier.
268
-
269
- ### The Old Way
270
-
271
- Here's an example of adding a view to our Cat class:
272
-
273
- class Cat < CouchRest::Model::Base
274
- property :name, String
275
- property :toys, [CatToy]
276
-
277
- view_by :name
278
- end
279
-
280
- The `view_by` method will create a view in the Cat's design document called "by_name". This will allow searches to be made for the Cat's name attribute. Calling `Cat.by_name` will send a query of to the database and return an array of all the Cat objects available. Internally, a map function is generated automatically and stored in CouchDB's design document for the current model, it'll look something like the following:
281
-
282
- function(doc) {
283
- if (doc['couchrest-type'] == 'Cat' && doc['name']) {
284
- emit(doc.name, null);
285
- }
286
- }
287
-
288
- By default, a special view called `all` is created and added to all couchrest models that allows you access to all the documents in the database that match the model. By default, these will be ordered by each documents id field.
289
-
290
- It is also possible to create views of multiple keys, for example:
291
-
292
- view_by :birthday, :name
293
-
294
- This will create an view of all the cats' birthdays and their names called `by_birthday_and_name`.
295
-
296
- Sometimes the automatically generate map function might not be sufficient for more complicated queries. To customize, add the :map and :reduce functions when creating the view:
297
-
298
- view_by :tags,
299
- :map =>
300
- "function(doc) {
301
- if (doc['model'] == 'Post' && doc.tags) {
302
- doc.tags.forEach(function(tag){
303
- emit(doc.tag, 1);
304
- });
305
- }
306
- }",
307
- :reduce =>
308
- "function(keys, values, rereduce) {
309
- return sum(values);
310
- }"
311
-
312
- Calling a view will return document objects by default, to get access to the raw CouchDB result add the `:raw => true` option to get a hash instead. Custom views can also be queried with `:reduce => true` to return reduce results. The default is to query with `:reduce => false`.
313
-
314
- Views are generated (on a per-model basis) lazily on first-access. This means that if you are deploying changes to a view, the views for
315
- that model won't be available until generation is complete. This can take some time with large databases. Strategies are in the works.
316
-
317
- ### View Objects
318
-
319
- Since CouchRest Model 1.1.0 it is now possible to create views that return objects chainable objects, similar to those you'd find in the Sequel Ruby library or Rails 3's Arel. Heres an example of creating a few views:
320
-
321
- class Post < CouchRest::Model::Base
322
- property :title
323
- property :body
324
- property :posted_at, DateTime
325
- property :tags, [String]
326
-
327
- design do
328
- view :by_title
329
- view :by_posted_at_and_title
330
- view :tag_list,
331
- :map =>
332
- "function(doc) {
333
- if (doc['model'] == 'Post' && doc.tags) {
334
- doc.tags.forEach(function(tag){
335
- emit(doc.tag, 1);
336
- });
337
- }
338
- }",
339
- :reduce =>
340
- "function(keys, values, rereduce) {
341
- return sum(values);
342
- }"
343
- end
344
-
345
- You'll see that this new syntax requires all views to be defined inside a design block. Unlike the old version, the keys to be used in a query are determined from the name of the view, not the other way round. Acessing data is the fun part:
346
-
347
- # Prepare a query:
348
- view = Post.by_posted_at_and_title.skip(5).limit(10)
349
-
350
- # Fetch the results:
351
- view.each do |post|
352
- puts "Title: #{post.title}"
353
- end
354
-
355
- # Grab the CouchDB result information with the same object:
356
- view.total_rows => 10
357
- view.offset => 5
358
-
359
- # Re-use and add new filters
360
- filter = view.startkey([1.month.ago]).endkey([Date.current, {}])
361
-
362
- # Fetch row results without the documents:
363
- filter.rows.each do |row|
364
- puts "Row value: #{row.value} Doc ID: #{row.id}"
365
- end
366
-
367
- # Lazily load documents (take last row from previous example):
368
- row.doc => Fetch last Post document from database
369
-
370
- # Using reduced queries is also easy:
371
- tag_usage = Post.tag_list.reduce.group_level(1)
372
- tag_usage.rows.each do |row|
373
- puts "Tag: #{row.key} Uses: #{row.value}"
374
- end
375
-
376
- #### Pagination
377
-
378
- The view objects have built in support for pagination based on the [kaminari](https://github.com/amatsuda/kaminari) gem. Methods are provided to match those required by the library to peform pagination.
379
-
380
- For your view to support paginating the results, it must use a reduce function that provides a total count of the documents in the result set. By default, auto-generated views include a reduce function that supports this.
381
-
382
- Use pagination as follows:
383
-
384
- # Prepare a query:
385
- @posts = Post.by_title.page(params[:page]).per(10)
386
-
387
- # In your view, with the kaminari gem loaded:
388
- paginate @posts
389
-
390
- ### Design Documents and Views
391
-
392
- 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.
393
-
394
- 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.
395
-
396
- 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:
397
-
398
- module CouchRestMigration
399
- def self.update_design_docs
400
- CouchRest::Model::Base.subclasses.each{|klass| klass.save_design_doc! if klass.respond_to?(:save_design_doc!)}
401
- end
402
- end
403
-
404
- # Running this from your applications initializers would be a good idea,
405
- # for example in Rail's application.rb or environments/production.rb:
406
- config.after_initialize do
407
- CouchRestMigration.update_design_docs
408
- end
409
-
410
- 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:
411
-
412
- module CouchRestMigration
413
- def self.update_all_design_docs
414
- update_design_docs(COUCHREST_DATABASE)
415
- Company.all.each do |company|
416
- update_design_docs(company.proxy_database)
417
- end
418
- end
419
- def self.update_design_docs(db)
420
- CouchRest::Model::Base.subclasses.each{|klass| klass.save_design_doc!(db) if klass.respond_to?(:save_design_doc!}
421
- end
422
- end
423
-
424
- # Command to run after a capistrano migration:
425
- $ rails runner "CouchRestMigratin.update_all_design_docs"
426
-
427
-
428
- ## Assocations
429
-
430
- Two types at the moment:
431
-
432
- belongs_to :person
433
-
434
- collection_of :tags
110
+ ### Preparations
435
111
 
436
- This is a somewhat controvesial feature of CouchRest Model that some document database purists may cringe at. CouchDB does not yet povide many features to support relationships between documents but the fact of that matter is that its a very useful paradigm for modelling data systems.
437
-
438
- In the near future we hope to add support for a `has_many` relationship that takes of the _Linked Documents_ feature that arrived in CouchDB 0.11.
439
-
440
- ### Belongs To
441
-
442
- Creates a property in the document with `_id` added to the end of the name of the foreign model with getter and setter methods to access the model.
443
-
444
- Example:
445
-
446
- class Cat < CouchRest::Model::Base
447
- belongs_to :mother
448
- property :name
449
- end
450
-
451
- kitty = Cat.new(:name => "Felix")
452
- kitty.mother = Mother.find_by_name('Sophie')
453
-
454
- Providing a object to the setter, `mother` in the example will automagically update the `mother_id` attribute. Retrieving the data later is just as expected:
455
-
456
- kitty = Cat.find_by_name "Felix"
457
- kitty.mother.name == 'Sophie'
458
-
459
- Belongs_to accepts a few options to add a bit more felxibility:
460
-
461
- * `:class_name` - the camel case string name of the class used to load the model.
462
- * `:foreign_key` - the name of the property to use instead of the attribute name with `_id` on the end.
463
- * `:proxy` - a string that when evaluated provides a proxy model that responds to `#get`.
464
-
465
- The last option, `:proxy` is a feature currently in testing that allows objects to be loaded from a proxy class, such as `ClassProxy`. For example:
466
-
467
- class Invoice < CouchRest::Model::Base
468
- attr_accessor :company
469
- belongs_to :project, :proxy => 'self.company.projects'
470
- end
471
-
472
- A project instance in this scenario would need to be loaded by calling `#get(project_id)` on `self.company.projects` in the scope of an instance of the Invoice. We hope to document and work on this powerful feature in the near future.
473
-
474
-
475
- ### Collection Of
476
-
477
- A collection_of relationship is much like belongs_to except that rather than just one foreign key, an array of foreign keys can be stored. This is one of the great features of a document database. This relationship uses a proxy object to automatically update two arrays; one containing the objects being used, and a second with the foreign keys used to the find them.
478
-
479
- The best example of this in use is with Labels:
480
-
481
- class Invoice < CouchRest::Model::Base
482
- collection_of :labels
483
- end
484
-
485
- invoice = Invoice.new
486
- invoice.labels << Label.get('xyz')
487
- invoice.labels << Label.get('abc')
488
-
489
- invoice.labels.map{|l| l.name} # produces ['xyz', 'abc']
490
-
491
- See the belongs_to relationship for the options that can be used. Note that this isn't especially efficient, a `get` is performed for each model in the array. As with a has_many relationship, we hope to be able to take advantage of the Linked Documents feature to avoid multiple requests.
492
-
493
-
494
- ## Validations
495
-
496
- CouchRest Model automatically includes the new ActiveModel validations, so they should work just as the traditional Rails validations. For more details, please see the ActiveModel::Validations documentation.
497
-
498
- CouchRest Model adds the possibility to check the uniqueness of attributes using the `validates_uniqueness_of` class method, for example:
499
-
500
- class Person < CouchRest::Model::Base
501
- property :title, String
502
-
503
- validates_uniqueness_of :title
504
- end
505
-
506
- The uniqueness validation creates a new view for the attribute or uses one that already exists. You can
507
- specify a different view using the `:view` option, useful for when the `unique_id` is specified and
508
- you'd like to avoid the typical RestClient Conflict error:
509
-
510
- unique_id :code
511
- validates_uniqueness_of :code, :view => 'all'
512
-
513
- Given that the uniqueness check performs a request to the database, it is also possible to include a `:proxy` parameter. This allows you to call a method on the document and provide an alternate proxy object.
514
-
515
- Examples:
516
-
517
- # Same as not including proxy:
518
- validates_uniqueness_of :title, :proxy => 'class'
519
-
520
- # Person#company.people provides a proxy object for people
521
- validates_uniqueness_of :title, :proxy => 'company.people'
522
-
523
-
524
- A really interesting use of `:proxy` and `:view` together could be where you'd like to ensure the ID is unique between several types of document. For example:
525
-
526
- class Product < CouchRest::Model::Base
527
- property :code
528
-
529
- validates_uniqueness_of :code, :view => 'by_product_code'
530
-
531
- view_by :product_code, :map => "
532
- function(doc) {
533
- if (doc['couchrest-type'] == 'Product' || doc['couchrest-type'] == 'Project') {
534
- emit(doc['code']);
535
- }
536
- }
537
- "
538
- end
539
-
540
- class Project < CouchRest::Model::Base
541
- property :code
542
-
543
- validates_uniqueness_of :code, :view => 'by_product_code', :proxy => 'Product'
544
- end
545
-
546
- Pretty cool!
547
-
548
- ## Proxy Support
549
-
550
- CouchDB makes it really easy to create databases on the fly, so easy in fact that it is perfectly
551
- feasable to have one database per user or per company or per whatever makes sense to split into
552
- its own individual database. CouchRest Model now makes it really easy to support this scenario
553
- using the proxy methods. Here's a quick example:
554
-
555
- # Define a master company class, its children should be in their own DB
556
- class Company < CouchRest::Model::Base
557
- use_database COUCHDB_DATABASE
558
- property :name
559
- property :slug
560
-
561
- proxy_for :invoices
562
-
563
- def proxy_database
564
- @proxy_database ||= COUCHDB_SERVER.database!("project_#{slug}")
565
- end
566
- end
567
-
568
- # Invoices belong to a company
569
- class Invoice < CouchRest::Model::Base
570
- property :date
571
- property :total
572
-
573
- proxied_by :company
574
-
575
- design do
576
- view :by_date
577
- end
578
- end
579
-
580
- By setting up our models like this, the invoices should be accessed via a company object:
581
-
582
- company = Company.first
583
- company.invoices.new # build a new invoice
584
- company.invoices.by_date.first # find company's first invoice by date
585
-
586
- Internally, all requests for invoices are passed through a model proxy. Aside from the
587
- basic methods and views, it also ensures that some of the more complex queries are supported
588
- such as validating for uniqueness and associations.
589
-
590
-
591
- ## Configuration
592
-
593
- CouchRest Model supports a few configuration options. These can be set either for the whole Model code
594
- base or for a specific model of your chosing. To configure globally, provide something similar to the
595
- following in your projects initializers or environments:
596
-
597
- CouchRest::Model::Base.configure do |config|
598
- config.mass_assign_any_attribute = true
599
- config.model_type_key = 'couchrest-type'
600
- end
601
-
602
- To set for a specific model:
603
-
604
- class Cat < CouchRest::Model::Base
605
- mass_assign_any_attribute true
606
- end
607
-
608
- Options currently avilable are:
609
-
610
- * `mass_assign_any_attribute` - false by default, when true any attribute may be updated via the update_attributes or attributes= methods.
611
- * `model_type_key` - 'model' by default, is the name of property that holds the class name of each CouchRest Model.
612
- * `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.
613
-
614
-
615
- ## Notable Issues
616
-
617
- None at the moment...
618
-
619
-
620
- ## Testing
112
+ CouchRest Model now comes with a Gemfile to help with development. If you want to make changes to the code, download a copy then run:
621
113
 
622
- The most complete documentation is the spec/ directory. To validate your CouchRest install, from the project root directory run `rake`, or `autotest` (requires RSpec and optionally ZenTest for autotest support).
114
+ bundle install
623
115
 
624
- ## Docs
116
+ That should set everything up for `rake spec` to be run correctly. Update the couchrest_model.gemspec if your alterations
117
+ use different gems.
625
118
 
626
- API: [http://rdoc.info/projects/couchrest/couchrest_model](http://rdoc.info/projects/couchrest/couchrest_model)
119
+ ### Testing
627
120
 
628
- Check the wiki for documentation and examples [http://wiki.github.com/couchrest/couchrest_model](http://wiki.github.com/couchrest/couchrest_model)
121
+ The most complete documentation is the spec/ directory. To validate your CouchRest install, from the project root directory run `bundle install` to ensure all the development dependencies are available and then `rspec spec` or `bundle exec rspec spec`.
629
122
 
123
+ We will not accept pull requests to the project without sufficient tests.
630
124
 
631
125
  ## Contact
632
126
 
@@ -636,3 +130,4 @@ Follow us on Twitter: [http://twitter.com/couchrest](http://twitter.com/couchres
636
130
 
637
131
  Also, check [http://twitter.com/#search?q=%23couchrest](http://twitter.com/#search?q=%23couchrest)
638
132
 
133
+