I think Mango needs _something_ to allow folks to process data between the
document and the index - thanks for posting Jan!.
I had a think about this and came up with another simpler syntax which is
in this gist:
https://gist.github.com/glynnbird/ad932de13eb0e276e6ffab5fcaa350f8
Cheers
Glynn
O
I've commented in the pull request:
https://github.com/apache/couchdb/pull/3582#issuecomment-848792131
On Wed, 26 May 2021 at 14:30, Garren Smith wrote:
> Hi Hannes,
>
> First off, thank you for contributing the PR. The code looks good, I have
> commented that we need two more tests.
> In terms
Is there a possibility that a future replicator, instead of consuming the
"firehose" changes feed, could instead be split into
1-worker-per-changes-feed-shard as a neat way of parallelizing data
transfer?
If there is to be a configurable changes feed shard count, what would be
the default? 1 assum
b.com/apache/couchdb-documentation/pull/609
On Mon, 30 Nov 2020 at 19:12, Glynn Bird wrote:
> I will. I did start to look at this then got sidetracked. I'll look this
> week.
>
> On Mon, 30 Nov 2020 at 19:01, Joan Touzet wrote:
>
>> Glynn, might you find time to work on
eed the multi-step
> > process.
> >
> > -Joan
> >
> > On 09/11/2020 03:55, Glynn Bird wrote:
> >> It turns out that branch protection doesn't require Infra intervention,
> >> there's a bunch of configuration flags that can be switched on
figuration example would be:
github:
protected_branches:
main
On Thu, 5 Nov 2020 at 11:59, Glynn Bird wrote:
> Created Infra ticket https://issues.apache.org/jira/browse/INFRA-21076
>
> On Wed, 4 Nov 2020 at 16:48, Glynn Bird wrote:
>
>> https://github.com/apache/couchdb-
Created Infra ticket https://issues.apache.org/jira/browse/INFRA-21076
On Wed, 4 Nov 2020 at 16:48, Glynn Bird wrote:
> https://github.com/apache/couchdb- main not protected
> https://github.com/apache/couchdb-fauxton- main not protected
> https://github.com/apache/couchdb-docker -
https://github.com/apache/couchdb-helm - main not protected
...
There are numerous others. I couldn't find an example where the main branch
_was_ protected, but in most cases the old master branch was.
Glynn
On Wed, 4 Nov 2020 at 16:36, Glynn Bird wrote:
> I'm on it.
>
> Glyn
> Would you be willing to volunteer to check and see which ones have
> unprotected main branches - at least for the big 4-5 or so (couchdb,
> docs, fauxton come to mind)?
>
> -Joan
>
> On 04/11/2020 11:13, Glynn Bird wrote:
> > I've published the 9.0.0 release of
I've published the 9.0.0 release of Nano, the Node.js library for CouchDB
which features:
- request library replaced with axios 👩🔧
- rewritten changes follower 🚿
- fewer dependencies 📉
https://www.npmjs.com/package/nano
Thanks to all who helped in the work to build and test this release.
While
Speaking to lots of Cloudant users, not many use custom JavaScript
reducers. Those that do are mainly doing so to reduce multiple values,
which can be achieved by emitting an array or an object and using a
built-in reducer.
I too am +1 to #2 (disable by default), and +0 neutral on #1
On Tue, 13
macOS 10.15.6
- checksums ok
- build ok (had to use erlang@22 instead of default erlang @23 that brew
gave me)
- 3 tests failed repeatedly
chttpd_view_test:75: should_succeed_on_view_with_queries_keys...*failed*
chttpd_view_test:91:
should_succeed_on_view_with_queries_limit_skip...*failed*
chttpd_
+1
Happy to help reconfigure apache/couchdb-nano if necessary after the switch
to main
On Thu, 10 Sep 2020 at 10:40, Andy Wenk wrote:
> strong +1
>
> here at sum.cumo we also change the “master” branches to main
>
> Best
>
> Andy
> --
> Andy Wenk
> Hamburg
>
> GPG fingerprint C32E 275F BCF3 9DF
It's confusing that the group_level parameter would behave differently, as
Joan points out, between CouchDB versions. Perhaps if group_level were to
be deprecated in CouchDB 4+, to be replaced by a new parameter
group_depth/depth/grouping or some such, that behaves as Garren proposes?
Or does that
If you need a relatively small list of partition keys, (let's say you want
to allow a user to paginate through the partition keys in blocks of 10,
say) then it's probably more efficient to perform a sequence of calls to
_all_docs, fetching the "first" document of each partition key like so:
https:
I've worked with folks using partitioned database so I thought I'd drop my
experience of that here:
- partitioned databases can definitely give a performance boost (in CouchDB
< 4 scenarios) to use-cases where the main "read" use-case can be directed
to a single partition. In such cases, only a fr
I don't think a whole new API is required here, but I would like to see
some sort of "bookmark" facility for _all_docs and views, as pagination
with the current API is awkward.
I would imagine it working as follows:
// first request
curl $URL/mydb/_all_docs?startkey="aardvark"&endkey="moose"&limi
> The quoting here is weird. Are you saying to skip _all_docs in your
proposal, Glynn?
I'm saying eliminate (3) from your list of things.
1. If user specifies an index, use it even if we have to wait
2. If an index is built that can be used, use it
3. n/a
4. As a last resort use _all_docs
On Th
+1 on removing step 3 - my reservation on falling back on all_docs is that
users have no insight into how expensive a query is, other than measuring
latencies (which might depend on other factors). I would hope that folks
would use option 1 anyway.
So Paul's list becomes:
1. If user specifies an
It's not something I was aware of, but it's certainly a known "feature",
documented here:
https://docs.couchdb.org/en/stable/ddocs/views/collation.html#all-docs
(probably because all keys are strings in all_docs, whereas they can be all
sorts of mixed types with a view, and ascii collation would b
Agree with Will that falling back to _all_docs-powered queries is usually
undesirable in all but the smallest data sets. More folks than you'd think
end up going into production without the right index because the
_all_docs-powered query in development (with a small data set) seemed to be
fast enou
If a user didn't specify the index they wanted to use, leaving the choice
of index up to CouchDB, I would expect Couch would ignore the partially
built index and fall back on _all_docs. so +1 on this.
But we need also consider the API response if a user *specifies* an index
during a query (with us
This feature is a great way for beginners to experiment with Mango but I
think it would be fine to limit this "index all" operation to top level
strings/numbers/booleans/arrays - this is the approach that DynamoDB takes
to limit the complexity it has to deal with (together with a 400kB document
siz
I'm happy to provide another PR to clean up the package.json.
Currently we have developers providing fixes to the dscape/nano project
(the original source of this project). It would be preferable if
- nano's package.json pointed to https://github.com/apache/couchdb-nano
- dscape/nano's readme cou
[
https://issues.apache.org/jira/browse/COUCHDB-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14367148#comment-14367148
]
Glynn Bird commented on COUCHDB-2641:
-
That fixes it thanks.
> Fresh b
Glynn Bird created COUCHDB-2641:
---
Summary: Fresh build of CouchDB 2.0 Developer Preview fails to
start - "Could not open file ... nodes.couch"
Key: COUCHDB-2641
URL: https://issues.apache.org/jira/brow
Glynn Bird created COUCHDB-2538:
---
Summary: GET /db/doc?open_revs={} produces unsual response in
CouchDB 2.0
Key: COUCHDB-2538
URL: https://issues.apache.org/jira/browse/COUCHDB-2538
Project: CouchDB
Glynn Bird created COUCHDB-2537:
---
Summary: Propose removal of ?local_seq=true from the GET /db/doc
API for CouchDB 2.0
Key: COUCHDB-2537
URL: https://issues.apache.org/jira/browse/COUCHDB-2537
Project
Glynn Bird created COUCHDB-2522:
---
Summary: CouchDB 2.0 /_changes feed does not return full
attachment data with attachments=true
Key: COUCHDB-2522
URL: https://issues.apache.org/jira/browse/COUCHDB-2522
[
https://issues.apache.org/jira/browse/COUCHDB-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14251860#comment-14251860
]
Glynn Bird commented on COUCHDB-2518:
-
I've reproduced this on 2.0
30 matches
Mail list logo
