On 17 May 2011 21:12, Paul Davis wrote:
> Fairly straight forward I suppose. Bigger question is whether its a good idea.
Why wouldn't it be a good idea?
Here's the problem I face:
The application I'm working on can potentially do lots of sequential
updates to separate documents (using requests
Is it possible to do bulk updates with an _update handler? Having
looked at the CouchDB code it doesn't look like it. Would there be any
value in this as a feature? Would it, in theory, be a fairly
straight-forward addition?
On 16 April 2011 16:42, Alexander Shorin wrote:
> On Sat, Apr 16, 2011 at 7:26 PM, Joe Freeman wrote:
>> Is there a way to pass the _changes feed (with include_docs=true)
>> through a map function (for example, one that exists as part of an
>> existing view)? If not, are the
On 16 April 2011 16:42, Alexander Shorin wrote:
> On Sat, Apr 16, 2011 at 7:26 PM, Joe Freeman wrote:
>> Is there a way to pass the _changes feed (with include_docs=true)
>> through a map function (for example, one that exists as part of an
>> existing view)? If not, are the
Is there a way to pass the _changes feed (with include_docs=true)
through a map function (for example, one that exists as part of an
existing view)? If not, are there any plans for this?
How about you just always send the user to the local instance if they
have couch installed by putting '127.0.0.1 app.com' in /etc/hosts (or
similar). Then you don't have to worry about the 'remote'/'local'
subdomain. Anyone that doesn't have couch installed (and hence doesn't
have the customised /e
I've never tried out COPY, but I suspect this is because when you copy
the document over, the document's 'name' property stays the same
('q...@q.qa'). When the new document is validated, it has an ID of
'org.couchdb.user:xxx', but the name property is 'q...@q.qa'. The
validation rule requires that
On 1 February 2011 18:04, Paul Davis wrote:
> I don't see anything direct with a view for this either. You could do
> it for a given part at a time, but not all parts in one request. One
> thing you might try is to use a _list function with your original set
> up to discard results you don't need.
On 1 February 2011 16:08, Paul Davis wrote:
> I'm not entirely certain what you're wanting for output. Could you
> give an example of what you'd hoped to achieve?
Sorry, let me try and give a better explanation...
A document (in my application; not a CouchDB document) is made up of a
number of p
Thanks for your feedback Paul.
On 27 January 2011 23:57, Paul Davis wrote:
> You're best bet would be to make another view that you can use to get
> what you want. For instance, if you want the revisions that existed
> for a given document before a certain time just create a second view
> that do
Hi CouchDB users,
I'm trying to explain my problem as clearly as possible. Please bear with me...
I have a view with a map function that is producing key-value pairs like this:
["document1","part1.1",1294696806874] -> {"content": "part 1.1, revision 3"}
["document1","part1.1",1294696793572] -> {
are there any plans to implement something like this in the future?
Thanks.
[1]
http://jchrisa.net/drl/_design/sofa/_list/post/post-page?startkey=%5B%22Versioning-docs-in-CouchDB%22%5D
On 2 January 2011 11:52, Joe Freeman wrote:
> I'm trying to implement document versioning using
My understanding of the CouchDB '_users' table is that in order to
have a user sign up (for example, using $.couch.signup(...)), you have
to have the '_users' table publicly visible, and hence have all users
in your app publicly visible?
This doesn't seem so great for me, or the potential users of
I'm trying to implement document versioning using a variation of the
method described under 'Multiple Documents' here:
http://blog.couchone.com/post/632718824/simple-document-versioning-with-couchdb
(I'd like to have been able to use the 'attachPrevRev' approach, but
unfortunately that doesn't see
14 matches
Mail list logo
