Grr, I tried to send this earlier today but just got a delivery failure notification. Oh well, here's the re-send
> Nice work Filipe. This has been on the roadmap for a long time. I have a > couple of questions: > > 1) Does the patch insert the ID of the _local checkpoint doc into the > _replicator doc? I think that would be pretty useful. > > 2) Multiple identical replications running makes me very uneasy. Does the > patch also break the behavior of /_replicate in that respect? > > 3) Is the checkpoint ID generation algorithm backwards-compatible? Or will > users who upgrade restart all replications from scratch? > > I'm not sure I fully understand the max_dbs_open concern. If you're hitting > all_dbs_active errors, that means a) you must have at least max_dbs_open > concurrent requests for different DBs running, or b) there's a bug in the ref > counting code. If it's a), that's a sign to increase the max_dbs_open limit. > > An infinite LRU timestamp for system DBs seems like a decent thing to do, but > in this case is it being used to hide a bug? Best, > > Adam On May 19, 2010, at 10:35 AM, Jan Lehnardt wrote: > Hi all, > > Filipe, great work! > > I think separate DBs make sense, but with a different angle. > > Say I want to replicate all users to a new instance. I don't want to > write a replication filter for that. > > Replicating replication tasks sounds like a nice meta-CouchDB- > programming thing I want to explore. People could benchmark > their clusters by how many levels of replication it can take (think > recursion :) > > I see more "tasks" coming up in the future, say continuous compaction, > or compaction when certain events happen. For this, a single DB _tasks > would make sense to keep replication, compaction and whatever other > tasks we can come up with. > > Users are not tasks, so they should be separate. Also, the _users db is > special cased in our auth-system, I'd rather not intermingle it with items > that don't need as high security (not saying you shouldn't be able to > hide tasks, but it is a different thing). > > Cheers > Jan > -- > > > On 19 May 2010, at 16:16, Filipe David Manana wrote: > >> I also tend to prefer having two separate DBs. For now, there are 2 specific >> resources (users and replications) but tomorrow we can have 3, 4, 5, etc. >> >> However, a single _system DB would help with the max_open_dbs and _stats :) >> >> >> >> On Wed, May 19, 2010 at 2:32 PM, Simon Metson >> <simonmet...@googlemail.com>wrote: >> >>> +1 >>> >>> >>> On 19 May 2010, at 12:59, Sebastian Cohnen wrote: >>> >>> having dedicated endpoints for specific resources sounds more reasonable >>>> to me, than having a single endpoint for misc stuff. just my 2ct >>>> >>>> >>>> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote: >>>> >>>> On Wed, May 19, 2010 at 13:13, Robert Dionne >>>>> <dio...@dionne-associates.com> wrote: >>>>> >>>>>> This sounds like a good approach, if I get the gist of it, it makes the >>>>>> replication state persistent. We also have a _users db now, is this a >>>>>> good >>>>>> time to think about consolidating and having one _system database ? >>>>>> >>>>> >>>>> I too like the proposal, but I'd also prefer a single _system db >>>>> rather than a bunch of specific databases. >>>>> >>>>> Cheers, >>>>> >>>>> Dirkjan >>>>> >>>> >>>> >>> >> >> >> -- >> Filipe David Manana, >> fdman...@gmail.com >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >
