From @javierg in testing something else

+++ b/lib/dolly/request.rb
@@ -19,7 +19,7 @@ module Dolly
       @password      = options["password"]
       @protocol      = options["protocol"]

-      @bulk_document = Dolly::BulkDocument.new []
+      @bulk_document = Dolly::BulkDocument.new self, []
       self.class.base_uri "#{protocol}://#{host}:#{port}"
     end

Ideally, a method on Dolly::Document to get attached files and return their binary data.

We can achive this thorugh Update Handlers It will require some convention on how to create the handler functions... as doing them dynamically is too costly, they will need to be created ahead. Here is were a generater might work.

Implement an interface for common active_record persistence predicates such as present? exists? blank?

https://github.com/vcr/vcr or add couchdb

We need to have actual integration tests, and FakeWeb is holding us back

builds of #93 and #94

create a standardized way for dolly to have attachments and retrieve attachments as per http://docs.couchdb.org/en/1.6.1/api/document/attachments.html

We need to add support for

https://wiki.apache.org/couchdb/HTTP_Bulk_Document_API

this will hugely improve the performance of update collections

right now we are sending everything under the query arguments, we need to switch and use POST data, since this will allow to push a bigger request

Add an interface on dolly to setup and trigger replications. Both.

Seems a little arbitrary at the moment, and before I start hacking around I'm wondering if there's an existing design decision on what belongs where?

I actually expected that the model would inherit from Document, and then I look in Base and I see things like property and I'm not sure why that's there and not in Document.

@rubenrails @javierg @netlogics @norcal82 what areas of the code have little to no documentation? what should we have documented better. Lets discuss so we can make focused Issues for each thing that needs better documentation

class Foo
  def bar
    doc['bar']
  end

  def bar= val
    doc['bar'] = val
  end
end

Calling @foo.bar invokes the writer as well as the reader for the attribute.

CouchDB's view collation allows returning multiple types in a single response. Collection need to be aware of this and thus instantiate the correct type instead of the default passed docs_class.

There's a passing test for timestamps, but they don't actually work.

The test is using a mock, Imho we should use a Factory instead, because that would be failing.

It's possible that #32 might help the issue, because its a date/time related situation.

@netlogics recommended adding a touch option when saving a record. Example offered was:

if timestamps
  set_created_at
  set_updated_at unless options[:touch] == false

We have implemented persisted? in WS using the presence of _rev, we could probably implement it directly into Dolly.

def persisted?
  doc['_rev'].present?
end

This method will set all the values, specially the rev id with what is on the remote document

Is a common pattern in CouchDb to add references to docs as properties in a parent doc. CouchDb have the View Collation concept.

We want to an interface from Dolly to this views.

If you have a nested attribute:

'sender': {
  type: 'mysql',
  id: 1
}

doc['sender'] works, but doc['sender']['id'] doesn't work, you have to do doc['sender'][:id]. There's some weird inconsistencies, sometimes you need strings, sometimes symbols.

In other applications, you must use doc['property'] to access the property correctly. otherwise it just reads default values.

Add a changes interface between Ruby and Couchdb

WIP
Open discussion for adding enumerable methods to Dolly::Colection.

Right now, the db:design task will only import map and reduce functions, we need to be able to import a broader range of functions.

One thing I was thinking is that you could actually have just a single view for all the ID-based lookups, as long as you stick to that "type/id" format for the _ids.

(d) ->
  if ti = d._id.split "/"
    emit ti

And then your view queries need to include that composite key, eg.

/foo/_design/dolly/_view/id?key=["User", "[email protected]"]

Please see https://github.com/amco/ab/pull/693

I believe this is due to the differences between the property method and what is stored in doc

Steps to reproduce:

1. Create a dolly document with the following: property :foo, class_name: Hash, default: {}
2. in couch directly save an instance of this document, and make sure foo is not included (i.e foo should not be a key anywhere in the document)
3. load the document via find. set document.foo = { 'bar' => 'baz' } and save.
4. In couch, the data will be foo: null and NOT foo: { 'bar' : 'baz' }

Currently, there are a couple of ways of achieving this, either by overriding the id method entirely, or by using a callback (e.g. before_save).

It'd be better if we could do something like:
Option A)

class Product < Dolly::Document
  property :sku, primary: true
end

Option B)

class Product < Dolly::Document
  property :sku

  primary :sku
end

p = Product.new
p.sku = "sau101"
p.id # "product/sau101"

It should work with either document propertys or arbitrary instance methods.

Users should be able to add filename.lib.coffee files to the db/designs folder and have them imported as views are. This will give users the ability to put JS code in modules and keep our views DRY

https://wiki.apache.org/couchdb/CommonJS_Modules

views: {
      lib: { 
        module_name: "exports.bar = 42;" 
}

Update the error handling to provide info when your connection to couch is blocked for auth reasons.

Add some more errors to map to all responses for HTTP RESTful API

save! should check if object responds to valid? and raises an exception if invalid.

CouchDb recommends that applications should define the id by themselves. We need to add a primary_key method on the Document definition, to make this possible.

:D

Real internet connections are disabled in the test suite, but it looks like they should be allowed to localhost.

There are 9 tests that are erroring because they aren't allowed to hit the database. If you allow localhost, then there's 5 failing.

property :build_log, :publishing_log, class_name: Array, default: []

is different than

property :build_log, class_name: Array, default: []
property :publishing_log, class_name: Array, default: []

probably something like
extend ActiveModel::Translation

see discussion here https://github.com/amco/asa/pull/228#discussion-diff-34929227

Currently we are usingCGI.encode in the Dolly::Document class, however they are more appropriate in the Dolly::Request class.

Main offender:

• https://github.com/amco/dolly/blob/1.0/lib/dolly/document.rb#L98

https://github.com/amco/dolly/blob/master/test/document_test.rb#L330

Given this line:
property :created_at, class_name: Time, default: Time.now

It appears that default is only run at the time the attribute is read.

It would be really cool if default actually populated the attribut before save, then it could be used for timestamps and all kinds of other fun defaulty type stuff.

After you set a property as default, You are not able to change the value of the property.