On 26 November 2013 17:10, Benjamin Young byo...@bigbluehat.com wrote:
This is a nit...maybe...but can we be sure that `_utils/fauxton` and
`_utils/fauxton/` both work? :)
Would prevent rock in shoe sort of frustrations. :)
true :) but that would mean you are not allowed to create a
GitHub user timblack1 opened a pull request:
https://github.com/apache/couchdb/pull/110
Handle req.status == 201
The reason for this fix is that without it, bulkSave() returns the
following error on line 1029:
Uncaught The documents could not be saved: undefined
What are we going to do with patches for query.couch? It seems everyone is
happy to deprecate it. We just now need someone who would be willing to
maintain it outside of the git repo?
Cheers
Garren
On 27 November 2013 at 11:58:11 AM, timblack1 (g...@git.apache.org) wrote:
GitHub user
On Wed, Nov 27, 2013 at 2:12 PM, Garren Smith gar...@apache.org wrote:
What are we going to do with patches for query.couch? It seems everyone is
happy to deprecate it. We just now need someone who would be willing to
maintain it outside of the git repo?
If nobody minds and/or don't plan to
Awesome, thanks Alexander.
On 27 November 2013 at 12:46:27 PM, Alexander Shorin (kxe...@gmail.com) wrote:
On Wed, Nov 27, 2013 at 2:12 PM, Garren Smith gar...@apache.org wrote:
What are we going to do with patches for query.couch? It seems everyone is
happy to deprecate it. We just now need
On 27. November 2013 at 11:51:17, Garren Smith (gar...@apache.org) wrote:
Awesome, thanks Alexander.
On 27 November 2013 at 12:46:27 PM, Alexander Shorin (kxe...@gmail.com)
wrote:
On Wed, Nov 27, 2013 at 2:12 PM, Garren Smith
wrote:
What are we going to do with patches for
On Wed, Nov 27, 2013 at 3:34 PM, Dave Cottlehuber d...@jsonified.com wrote:
On 27. November 2013 at 11:51:17, Garren Smith (gar...@apache.org) wrote:
Awesome, thanks Alexander.
On 27 November 2013 at 12:46:27 PM, Alexander Shorin (kxe...@gmail.com)
wrote:
On Wed, Nov 27, 2013 at 2:12 PM,
A major version bump (not to mention, a discussion) is needed if we're
to remove a long-standing component like jquery.couch.js. For my part,
I'm -1 on removing it having heard no good reason for doing so.
B.
On 27 November 2013 11:39, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Nov 27,
On 11/27/2013 12:39 PM, Alexander Shorin wrote:
We'll break every couchapp that uses it in his UI. Later the same
fates awaits any other js lib, that ships with futon, but will not be
available in fauxton.
I don't think this is going to be a big issue if you still provide the
libs to get
On Wed, Nov 27, 2013 at 3:49 PM, meredrica st...@meredrica.org wrote:
On 11/27/2013 12:39 PM, Alexander Shorin wrote:
We'll break every couchapp that uses it in his UI. Later the same
fates awaits any other js lib, that ships with futon, but will not be
available in fauxton.
I don't think
I think NPM mostly struggle with disk issues (all attachments in the
same file, it's 100G) and replication (a document with lots of
attachments has to be transferred fully in the same connection without
interruption or else it starts over).
Both of these are fixable without taking the extreme
On Wed, Nov 27, 2013 at 3:48 PM, Robert Newson rnew...@apache.org wrote:
A major version bump (not to mention, a discussion) is needed if we're
to remove a long-standing component like jquery.couch.js. For my part,
I'm -1 on removing it having heard no good reason for doing so.
Agreed with
It's the other way around. If the next release removes jquery.couch.js
then it gets called 2.0.0. It doesn't imply we wait for 2.0. The
version *only* conveys compatibility, that's the semver way.
On 27 November 2013 12:01, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Nov 27, 2013 at 3:48
If the library is getting taken out to be maintained in an external repo why
not just maintain it in the asf one? The reason for deprecating it would be to
be honest that it’s not maintained code, if someone is maintaining it then
great, keep it in!
That it’s not used by fauxton is
On 11/27/2013 12:57 PM, Alexander Shorin wrote:
Suddenly, nobody reads release notes, especially upgrade one and
these competent are exists for to long to let people be sure in them -
we don't know how much pages we'll broke by this move. So it's
definitely requires major version bump like
On Wed, Nov 27, 2013 at 3:59 PM, Robert Newson rnew...@apache.org wrote:
Particularly, we could make
attachment replication resumable. Currently, if we replicate 99.9% of
a large attachment, lose our connection, and resume, we'll start over
from byte 0. This is why, elsewhere, there's a
On Wed, Nov 27, 2013 at 4:05 PM, Robert Newson rnew...@apache.org wrote:
It's the other way around. If the next release removes jquery.couch.js
then it gets called 2.0.0. It doesn't imply we wait for 2.0. The
version *only* conveys compatibility, that's the semver way.
I was about that there
On Wed, Nov 27, 2013 at 4:06 PM, Simon Metson si...@cloudant.com wrote:
If the library is getting taken out to be maintained in an external repo why
not just maintain it in the asf one? The reason for deprecating it would be
to be honest that it’s not maintained code, if someone is
Alex,
That's basically the right approach but I'll say it over in my own
words with some background;
The way a document with attachments is replicated is as follows;
1) All the bytes of the attachments are written, the offsets of the
starts of each chunk of each attachment is remembered in
where nothing changed,
Removing jquery.couch.js will *break* some users. Neither of us know
how many users that is, or which users it is. The major version bump
is necessary to communicate this (MAJOR version when you make
incompatible API changes). We can deprecate it without needing to
bump the
I'm also -1 on removing it. If we really plan to remove it we should do it
gracefully. Add a big note somewhere, maybe even in the header of the
source file notifying users that it will be deprecated.
Maybe even add a console.info or console.warn stating that it is a
deprecated library.
That way
Robert,
I understand all of this, but it seems we're talking about bit
different things. You're right that this change will require major
version bump - I'm totally agree on that.
But I'd talking about that if there already will be the window of
major version bump due to bigcouch/rcouch merges
On Wed, Nov 27, 2013 at 5:02 PM, Octavian Damiean odami...@linux.com wrote:
I'm also -1 on removing it. If we really plan to remove it we should do it
gracefully. Add a big note somewhere, maybe even in the header of the
source file notifying users that it will be deprecated.
Maybe even add a
On Wed, Nov 27, 2013 at 12:59 PM, Robert Newson rnew...@apache.org wrote:
I think NPM mostly struggle with disk issues (all attachments in the
same file, it's 100G) and replication (a document with lots of
attachments has to be transferred fully in the same connection without
interruption or
I am on-record as supportive of npm's needs here but still skeptical or at
least unclear on the fix.
Pain points:
1. Replicating the registry can have problems. Best-case scenario you have
to download 100GB of data (and growing exponentially)
2. Bandwidth costs of the primary service
Both
replicate 100GB (and growing) data just to have a local npm web service.
This makes no sense to me. Of course you have to have a local copy of
all the things to have a local npm web service. Are we talking about
partial mirroring instead then? If so, filtered replication has you
covered, right?
Damien used to say, there are vitamins and there are pain pills.
Bigcouch is a vitamin[1]: a long-term fix to the general health and
robustness of the system.
npm needs a pain pill. And it is going to get one. Why do I respect the
Node.js community? Certainly not because of the language! No,
Yes, I think it is quite likely that an alternative replicator comes out
soon. This replicator can be tailored to npm's needs, such as only
replicating a subset of the documents[1] (Replicate only package X, Y, and
Z plus their dependencies). Or possibly even only replicating a subset of
that
Dear devs,
First of all I would like to thank Alexander Shorin for his detailed
description of the replication algorithm, see [1][2].
The timing was outstanding: I was working on a JavaScript
implementation of the replication algorithm with the goal to better
understand how replication works.
I
Isaac Z. Schlueter created COUCHDB-1940:
---
Summary: Add digest_raw and size_raw to compressed _attachments
entries
Key: COUCHDB-1940
URL: https://issues.apache.org/jira/browse/COUCHDB-1940
Isaac Z. Schlueter created COUCHDB-1941:
---
Summary: Support all doc-related flags in _changes feed if
include_docs=true
Key: COUCHDB-1941
URL: https://issues.apache.org/jira/browse/COUCHDB-1941
+1 for
console.info,
waiting till 2.0
and communicating it prominently
Cheers
Andy
On 27 November 2013 14:29, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Nov 27, 2013 at 5:02 PM, Octavian Damiean odami...@linux.com
wrote:
I'm also -1 on removing it. If we really plan to remove it
Awesome!
On 11/27/2013 06:09 PM, Johannes Jörg Schmidt wrote:
Dear devs,
First of all I would like to thank Alexander Shorin for his detailed
description of the replication algorithm, see [1][2].
The timing was outstanding: I was working on a JavaScript
implementation of the replication
On Wed, Nov 27, 2013 at 3:07 PM, Jason Smith j...@apache.org wrote:
I am on-record as supportive of npm's needs here but still skeptical or at
least unclear on the fix.
Pain points:
1. Replicating the registry can have problems. Best-case scenario you have
to download 100GB of data (and
[
https://issues.apache.org/jira/browse/COUCHDB-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13834395#comment-13834395
]
Jan Lehnardt commented on COUCHDB-1941:
---
These discussions are related.
Support
Awesome, Johannes!
Looks like my protocol definition even works (: Have you found any
issues or some missing, incorrect, unclear, weird and others things
in the doc during implementation? Except your comments on github - I'm
keeping them in mind, don't worry about.
Also, you might be interested
36 matches
Mail list logo
