CouchDB update design functions call

20 views
Skip to first unread message

Kxepal

unread,
May 16, 2011, 8:57:26 AM5/16/11
to couchdb...@googlegroups.com
Hi!

Have someone any suggestions or thoughts about API to call document update handlers on CouchDB side? Currently it's a little harder to implement such functionality for Database object due to there is already exists update function which is used for documents bulk operations. How this conflict could be resolved?

Matt Goodall

unread,
May 17, 2011, 4:15:31 AM5/17/11
to couchdb...@googlegroups.com
On 16 May 2011 13:57, Kxepal <kxe...@gmail.com> wrote:
Have someone any suggestions or thoughts about API to call document update handlers on CouchDB side? Currently it's a little harder to implement such functionality for Database object due to there is already exists update function which is used for documents bulk operations. How this conflict could be resolved?


Choosing the name 'update' for _bulk_docs was unlucky, but it's existed for a lot longer than CouchDB's update handlers. I did once suggest renaming update to bulk_save (mostly to match the Database.save method's name) but I wasn't expecting anyone to vote for that change ;-).

The best I can think of is calling the method that calls an update handler doc_update or update_doc. Not perfect, but I don't think they're so bad either as an update handler does operate on a single doc at a time.

- Matt

Kxepal

unread,
May 17, 2011, 11:16:03 AM5/17/11
to couchdb...@googlegroups.com
I could vote for this!(: However, backward compatibility should be saved and seems no way to make soft and easy rename. I like `update_doc` name because it would be placed right after `update`one in documentation reference and code completion tool tip, so developer would be forced to notice new function and read about their difference.

Should I write patch or you will finish this design functions trio?(:

Matt Goodall

unread,
May 17, 2011, 11:29:46 AM5/17/11
to couchdb...@googlegroups.com
On 17 May 2011 16:16, Kxepal <kxe...@gmail.com> wrote:
I could vote for this!(: However, backward compatibility should be saved and seems no way to make soft and easy rename. I like `update_doc` name because it would be placed right after `update`one in documentation reference and code completion tool tip, so developer would be forced to notice new function and read about their difference.

Should I write patch or you will finish this design functions trio?(:

If you have time to contribute a patch it would be great! My inbox is currently piling up with things I need to do (including some couchdb-python work). Oh, tests would be awesome too ;-).

- Matt

Kxepal

unread,
May 17, 2011, 11:34:50 AM5/17/11
to couchdb...@googlegroups.com

Ok, I'll put it for today todo list(:

---
,,,^..^,,,

prudhvi

unread,
May 17, 2011, 3:13:33 PM5/17/11
to CouchDB-Python
It would be nice if the update conflicts of a document is handled..
Or leave it to the developer?

Kxepal

unread,
May 17, 2011, 3:53:00 PM5/17/11
to couchdb...@googlegroups.com
On Tuesday, May 17, 2011 11:13:33 PM UTC+4, prudhvi wrote:
It would be nice if the update conflicts of a document is handled..
Or leave it to the developer?

Currently, all document conflicts raise ResourceConflict exception which must be catched and correctly proceeded. This is true for update handlers too. How they should be proceeded (retry with new revision, merge with new version or ask user to merge manually etc.) only developer knows(:
 
Reply all
Reply to author
Forward
0 new messages