Re: Save the date: ApacheCon North America, September 24-27 in Montréal

unsubscribe On Wed, Feb 21, 2018 at 3:21 AM, Rich Bowen wrote: > Dear Apache Enthusiast, > > (You’re receiving this message because you’re subscribed to a user@ or dev@ > list of one or more Apache Software Foundation projects.) > > We’re pleased to announce the upcoming

Re: suggestion for improvement

unneeded traffic. I could cache all the data sent to the client to compare in the server. I've also thought of writing a summary of what is changed on writes along with the document. I wanted to ask here before I went down any of these rabbit holes. On Wed, Apr 18, 2012 at 6:50 PM, Dominic Tarr

Re: suggestion for improvement

I'm think mark wants to know what has changed with the last update, rather than to keep every version around forever. On Fri, Apr 20, 2012 at 10:10 AM, Robert Newson rnew...@apache.org wrote: You can fetch previous revisions with ?rev=rev until compaction sweeps them away, but it's considered

Re: suggestion for improvement

you would need to respond to each item in the feed by making a request back to couch (since merely including the document is not sufficient, in your case) and then combining that into your own augmented changes feed, perhaps. On Fri, Apr 20, 2012 at 11:01 AM, Dominic Tarr dominic.t

Re: suggestion for improvement

couch just doesn't track things at that level, since versioning is done at the document level. how are you doing handling this at the moment? are you using a library to do a diff of the conflicted versions or something like that? On Thu, Apr 19, 2012 at 8:28 AM, Mark Hahn m...@hahnca.com wrote:

iterative map reduce

hi, I need a iterative map reduce, prefurably, in couchdb. I want to be able to do a map reduce to generate unique items, then another map reduce to generate stats about those unique items. from what I know about couchdb at the moment, it seems like id have to do the first step at the document

Re: Document design: Logging accesses to an item by a user

this might be easiest to achieve with a an update handler. you can create all kinds of atomic transactional things like that, on a single document though. the user requests the update handler, which updates the count for that user, and returns the song info, all in one request. On Sun, Nov 13,

Re: unique constraint in couchdb

so, a user may have a multiple timestamps, but they must all be unique? what do the timestamps represent? is there some other feature that could be in the key? or, could you use a update handler and put all timestamps per user in the same document? On Mon, Oct 24, 2011 at 7:48 AM, Michael

scalabitily of the _changes feed

is it okay to register a huge number of listeners to the changes feed? I notice that you can use a filter function, which gets passed the request parameters, does this mean that the filter function will be called for each doc, for each listener on the changes feed? or are the results of each

versioning views

hi, last time I did some couch db development, I ran into some difficulties managing view versions. so what I was thinking was, that this time i'll write a tool to manage their versions. basically, i'll save all the views with an id like: _design/whatever_v1.3.5 then, in my server code (which

Re: versioning views

them to the db. On Fri, Sep 23, 2011 at 7:34 AM, Dominic Tarr dominic.t...@gmail.com wrote: hi, last time I did some couch db development, I ran into some difficulties managing view versions. so what I was thinking was, that this time i'll write a tool to manage their versions

Re: Cross/Joined Database Access?

you would have to do multiple http requests, i think. would it be possible to combine all of the dbs into one database and just have a field = user1,user2 etc? somethings like this seem weird, coming from relational databases, but thats couchdb. On Tue, Mar 22, 2011 at 9:02 PM, Marc Schwering

Re: multiple database or many doc types in one database?

:37 PM, Paul Hirst paul.hi...@sophos.com wrote: On Thu, 2011-03-17 at 14:48 +, Kevin R. Coombes wrote: On 3/17/2011 3:46 AM, Paul Hirst wrote: On Thu, 2011-03-17 at 04:51 +, Dominic Tarr wrote: is it a good idea to 1. separate documents for different types of thing

Re: Some CouchDB internals questions?

do you know about the include_doc option on view queries? if you emit(key, doc) in the view, then the whole doc will be saved in the view cache, but if you query a view with the include_doc=true then the view results will include the whole doc. this is fetched from the db and not stored in the

multiple database or many doc types in one database?

is it a good idea to 1. separate documents for different types of thing into different databases? or is it better to 2. just have a type='whatever' and check for that in your views? I'm starting to think that 2 is enough seperation, and 2 is silly. are there any reason to use 2, except