do a non-blocking file:sync
---
Key: COUCHDB-767
URL: https://issues.apache.org/jira/browse/COUCHDB-767
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 0.11
For now I've uploaded it on github : http://github.com/dready92/futon-designer
I really don't think it's really for prime-time, so opening a JIRA request
seems too early for me...?
I kept the designer workflow separate from the database.html/document.html
page for a reason :
Dear all,
I've been working on the _replicator DB along with Chris. Some of you have
already heard about this DB in the mailing list, IRC, or whatever. Its
purpose:
- replications can be started by adding a replication document to the
replicator DB _replicator (its name can be configured in the
This sounds very awesome to me!
One question though: You just need to add a document to the _replicator DB and
don't have to wait for long-running replications to finish?
On 19.05.2010, at 11:31, Filipe David Manana wrote:
Dear all,
I've been working on the _replicator DB along with Chris.
On Wed, May 19, 2010 at 10:47 AM, Sebastian Cohnen
sebastiancoh...@googlemail.com wrote:
This sounds very awesome to me!
Thanks Sesbastian.
One question though: You just need to add a document to the _replicator DB
and don't have to wait for long-running replications to finish?
No, the
On 19 May 2010, at 09:05, mickael.bai...@free.fr wrote:
For now I've uploaded it on github : http://github.com/dready92/futon-designer
I really don't think it's really for prime-time, so opening a JIRA request
seems too early for me...?
I kept the designer workflow separate from the
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 ?
Good stuff,
Bob
On May 19, 2010, at 5:31 AM, Filipe David Manana 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
Constant Bulk Saving results in Eventual Timeouts
-
Key: COUCHDB-768
URL: https://issues.apache.org/jira/browse/COUCHDB-768
Project: CouchDB
Issue Type: Bug
Components: HTTP
+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
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
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.
[
https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869147#action_12869147
]
Adam Kocoloski commented on COUCHDB-767:
After chatting with rnewson on IRC I
[
https://issues.apache.org/jira/browse/COUCHDB-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-767:
---
Attachment: 767-async-fsync.patch
The patch.
do a non-blocking file:sync
Hey Noberto,
it is plain http. but of course there is a multitude of ways to secure/encrypt
http communication. ssl/tls aware proxies, ssh or vpn tunnels, you name it :)
Sebastian
On 19.05.2010, at 14:46, Norberto Fernandes FCS wrote:
Hi All,
Does anyone know the protocol or security
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
On Wed, May 19, 2010 at 12:35, Adam Kocoloski kocol...@apache.org wrote:
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
On May 19, 2010, at 2:17 PM, Randall Leeds wrote:
On Wed, May 19, 2010 at 13:06, Filipe David Manana fdman...@gmail.com wrote:
Answers bellow
On Wed, May 19, 2010 at 8:35 PM, Adam Kocoloski kocol...@apache.org wrote:
3) Is the checkpoint ID generation algorithm backwards-compatible? Or
[
https://issues.apache.org/jira/browse/COUCHDB-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Lehnardt closed COUCHDB-756.
Fix Version/s: 1.0
Resolution: Fixed
Credentials from replication are exposed in status
On Wed, May 19, 2010 at 14:32, J Chris Anderson jch...@apache.org wrote:
The main goals as I see them are:
1) replications continue even when the server restarts
2) it is easy to write replication manager couchapps
I think having the standard database API for these documents (even if it is
There are occasional reports on IRC about replication tasks that
'hang' or become 'defunct'. That is, the replication tasks are still
showing in _active_tasks but updates aren't getting copied over.
This occurs principally when one end is restarted and the other end
doesn't notice. If this
Store large attachments external to the .couch file
---
Key: COUCHDB-769
URL: https://issues.apache.org/jira/browse/COUCHDB-769
Project: CouchDB
Issue Type: New Feature
Components:
[
https://issues.apache.org/jira/browse/COUCHDB-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson updated COUCHDB-769:
--
Attachment: external_attachments_alpha.patch
For wider review purposes only! Work is
23 matches
Mail list logo
