It would be great to move to 23. It has quite a few interesting features, which
we could use.
Also as Nick said it would make switching to rebar3 easier.
+1 to the proposal
Best regards,
iilyak
On 2022/06/13 20:20:09 Nick Vatamaniuc wrote:
> Hello everyone,
>
> I'd like to propose making Erla
Hi Noah,
Thank you for the PR and the discussion thread. I am in favor of accepting this
change for main.
However would like to hear an opinion from one of the PMCs. Since it is a
breaking change which changes the behavior.
Best regards,
ILYA
On 2021/06/28 19:18:26, Noah Shaw wrote:
> Hi a
>
> >> In general I am +0.5 on the entire thing, but would like to see Bob
> >> Newson or Paul Davis speak up. In the past they've been the most vocal
> >> about code formatting standards, and I'd at least like to see a +0 from
> >> both of them.
Good idea Donat!!!
Even though I disagree with some of the choices made by erlfmt I appreciate
consistency it provides.
The choices are logical. I really love that every decision is documented and
properly discussed. I did read PR in its entirety and in fact was not even
noticed the ugly `->`
+1 for cleanup of the codebase
On 2021/04/12 16:25:42, Nick Vatamaniuc wrote:
> Hi all,
>
> Currently we have a bunch of 3.x applications in the main branch which
> are not functional. Some even start supervisors and expose HTTP
> endpoints, like _reshard (mem3). Initially the idea was to keep
Nice list of questions. Couple more from me:
# global vs per endpoint?
If we decide for API per endpoint we could different mechanisms to get list of
supported versions:
- new /_api endpoint which would return list of versions for each endpoint
```
{
"/{db}/{docid}": ["4", "55", "95
Hi,
In FDB world there wouldn't be erlang mesh as far as I can tell. In this
situation the `node` field in the response from `/_scheduler/jobs` and
`/_scheduler/docs` doesn't make sense.
We could either remove the field or set it to `None`. I propose complete
removal.
I also propose to est
Thank you Adam for bringing back API versioning discussion.
I think we should adopt API versioning. This would allow us to get a number of
benefits:
1. It would allow clients to choose appropriate API based on explicit API
version support returned response from /
2. It would allow us to run tw
l not pursue
> removal of our release branches.
>
> On 2020-10-29 5:56 a.m., Ilya Khlopotov wrote:
>
> > ❯ git describe --always --tags
> > archive/prototype/fdb-layer-get-doc-spans-580-gdfb27b48a
>
> but:
>
> $ git checkout 3.x
> Branch '3.x' set u
ocally that adds a fetch ref spec that excludes
> `archive/`?
>
> > On 29. Oct 2020, at 10:56, Ilya Khlopotov wrote:
> >
> > Hello,
> >
> > As you've probably know, recently old branches were archived. I tried to
> > build a new release locally and
Hello,
As you've probably know, recently old branches were archived. I tried to build
a new release locally and was very surprised that it couldn't start. After
scratching my head for few hours I figured out the following.
I used `git fetch` command without specifying specific branch. This cause
I wanted to share a failed approach just to save some time for anyone who is
thinking about the issue.
I thought we could change the key format of a by_seq index at the expense of
an extra LAST_LESS_THAN call on every doc write.
Currently the keys in by_seq index are `("changes", Sequence)`,
I would be +1 as long as it works and we have options to migrate archive
elsewhere if/when we need to.
You are proposing to mirror email traffic which means that mail archive would
have a complete history and spare the project from total vendor lock in.
Best regards,
ILYA
On 2020/05/11 19:04
Hello,
Thank you Robert for starting this important discussion. I think that the
values you propose make sense.
I can see a case when user would use hashes as document ids. All existent hash
functions I am aware of should return data which fit into 512 characters. There
is only one case which d
at our cursor can go stale/invalid after a short
> > > time.
> > >
> > > Bob, could you be a bit more detailed in your explanation how our
> > > definition isn't close to these? Or did you mean SQL CURSOR (which is
> > > something entirely diff
curious, in the latest proposal what will be included in the
> bookmark? Proposal said "The bookmark would include information needed
> to ensure proper pagination without the need to repeat initial
> parameters of the request".
>
> [1]
> https://github.com/apache/cou
ength, port and scheme length.
- what error to return?
I think option number 2 is too subtle to implement.
The downside of option 1 is it is a bit harder to use from the browser or curl.
On 2020/04/29 17:27:59, Ilya Khlopotov wrote:
> I think I addressed all comments and creat
I think I addressed all comments and created an RFC
https://github.com/apache/couchdb-documentation/pull/530
On 2020/04/28 11:56:15, Ilya Khlopotov wrote:
> Hello,
>
> I would like to introduce second proposal.
>
> 1) Add new optional query field called `bookmark` (or `token
uce API versioning and deal with `{db}/_changes` and
`_all_docs` endpoints.
Questions:
- `bookmark` vs `token`?
- should we prohibit setting other fields when bookmark is set?
- `previous`/`next`/`first` as href vs token value itself (i.e. `{"previous":
"983uiwfjkdsdf", &q
. The only thing I came up with was to have a
> > chttpd_handlers_v2.erl service that's called and then
> > chttpd_httpd_handlers_v2.erl that instead of defaulting to `no_match`
> > would just forward to `chttpd_httpd_handlers:url_handler(Req)` or w/e
> > it would be. But to be honest,
ers_v2.erl service that's called and then
> chttpd_httpd_handlers_v2.erl that instead of defaulting to `no_match`
> would just forward to `chttpd_httpd_handlers:url_handler(Req)` or w/e
> it would be. But to be honest, I'm not super fond of that approach.
>
> On Mon, Apr 27, 2020 at 2:41 PM Ilya Khlopoto
I've implemented a PoC for versioned API
https://github.com/apache/couchdb/pull/2832. The code is very ugly but it
demonstrates how it could work.
Best regards,
iilyak
On 2020/04/27 14:55:10, Ilya Khlopotov wrote:
> Hello,
>
> The topic of API versioning was brought in the [St
t in the first version, though it
> would allow a user to know if, say, they backed up consistent point in
> time snapshot of the database using a sequence of cursor requests.
>
> I am also +0 on returning "completed: true", I kind of like the idea.
> Maybe we could jus
Hello,
The topic of API versioning was brought in the [Streaming API in CouchDB
4.0](https://lists.apache.org/thread.html/ra8d16937cca332207d772844d2789f932fbc4572443a354391663b9c%40%3Cdev.couchdb.apache.org%3E)
thread. The tread proposes to add new API endpoints to introduce a response
structu
ther popular REST APIs.
>
> -Joan "still sick and not sleeping right" Touzet
>
>
> On 2020-04-23 12:30, Robert Newson wrote:
> > cursor has established meaning in other databases and ours would not be
> > very close to them. I don’t think it’s a good idea.
&
db}/_all_docs?limit=20&page=3
> >>>
> >>> I know that I'm always going to get document 41 through 60 in the default
> >>> collation order.
> >>>
> >>> There's a *fantastic* summary of exampl
&page=3
> > > >
> > > > I know that I'm always going to get document 41 through 60 in the
> > default collation order.
> > > >
> > > > There's a *fantastic* summary of examples from popular REST APIs here:
> > > >
> &g
y updated keys in the
range. I agree that it is currently not used and we can it when we decide it is
worth it.
Best regards,
iilyak
On 2020/04/22 20:18:57, Ilya Khlopotov wrote:
> Hello everyone,
>
> Based on the discussions on the thread I would like to propose a number of
hat happens if a node's time is an hour
> behind another node?
>
>
> On Thu, Apr 23, 2020 at 4:55 AM Ilya Khlopotov wrote:
>
> > - page is to provide some notion of progress for user
> > - timestamp - I was thinking that we should drop requests if user would
>
stamp is old? What happens if a node's time is an hour
> behind another node?
>
>
> On Thu, Apr 23, 2020 at 4:55 AM Ilya Khlopotov wrote:
>
> > - page is to provide some notion of progress for user
> > - timestamp - I was thinking that we should drop requests if
gt;
> I guess, why does the bookmark include so much extraneous data? Items that
> are not needed to find the fdb key to begin the next response from.
>
>
> > On 22 Apr 2020, at 21:18, Ilya Khlopotov wrote:
> >
> > Hello everyone,
> >
> > Based
Hello everyone,
Based on the discussions on the thread I would like to propose a number of
first steps:
1) introduce new endpoints
- {db}/_all_docs/page
- {db}/_all_docs/queries/page
- _all_dbs/page
- _dbs_info/page
- {db}/_design/{ddoc}/_view/{view}/page
- {db}/_design/{ddoc}/_view/{
Given that it unlikely that there are too many people using it and it is being
noop in FDB world. I think we should deprecate and remove _partition endpoint.
On 2020/04/20 21:04:58, Robert Samuel Newson wrote:
> Hi All,
>
> I'd like to get views on whether we should preserve the _partition en
ch?
> >
> > Adam
> >
> >> On Feb 18, 2020, at 2:13 PM, Ilya Khlopotov wrote:
> >>
> >> Currently we only trigger CI on attempts to merge to master branch. With
> >> ongoing effort to rebase CouchDB on top of FoundationDB it seems like we
>
Currently we only trigger CI on attempts to merge to master branch. With
ongoing effort to rebase CouchDB on top of FoundationDB it seems like we would
be running two projects in parallel for quite some time. The lack of CI on
merge to prototype/fdb-layer causes merges of broken code.
I am cur
Hi Paul,
Not sure if it would help you. I have following git alias:
```
[alias]
rmmerged = !sh -c \"git branch --merged | grep -v '^* master$' | grep
-v '^ master$' | xargs git branch -d\"
```
Also we might want to change the setting for repository to delete merged
branches.
BR,
iily
ue blobs, but they don’t look opaque in the RFC. Did that change?
>
> Adam
>
> > On Sep 16, 2019, at 3:38 PM, Ilya Khlopotov wrote:
> >
> > Hi,
> >
> > The RFC is ready for review
> > https://github.com/apache/couchdb-documentation/pull/440
> &g
Hi,
The RFC is ready for review
https://github.com/apache/couchdb-documentation/pull/440
Best regards,
ILYA (aka iilyak)
On 2019/09/10 18:32:03, Ilya Khlopotov wrote:
> Hi,
>
> I wanted to run this idea by the ML to see if there is any interest before
> investing time in
(aka iilyak)
On 2019/09/10 18:32:03, Ilya Khlopotov wrote:
> Hi,
>
> I wanted to run this idea by the ML to see if there is any interest before
> investing time into preparing formal RFC.
>
> # Problem statement
>
> Collecting profiling data is very tricky at the mo
t; > OpenTracing tracer is configured?
> >
> > I also think a full picture here might include the ability to inherit
> > client-provided spans, so an app developer could drill down from her own
> > code into the database internals and figure out why some DB request was
nclude the ability to inherit
> client-provided spans, so an app developer could drill down from her own code
> into the database internals and figure out why some DB request was
> unexpectedly slow.
>
> Thanks for starting this discussion. Cheers,
>
> Adam
>
> > On Sep
Hi,
I wanted to run this idea by the ML to see if there is any interest before
investing time into preparing formal RFC.
# Problem statement
Collecting profiling data is very tricky at the moment. Developers have to run
generic profiling tools which are not aware of CouchDB specifics.
This ma
gt; getting this working. But I don't think we can stay on rebar2 forever
> either. Adding in erlang dependancies is becoming increasingly more
> difficult as they expect rebar3.
>
> Cheers
> Garren
>
> On Fri, Aug 16, 2019 at 2:02 PM Ilya Khlopotov wrote:
>
> >
On 2019/08/15 18:51:29, Joan Touzet wrote:
> Hi Ilya,
>
>
> On 2019-08-15 10:09, Ilya Khlopotov wrote:
> > Hello,
> >
> > There is an https://github.com/apache/couchdb/issues/1428 issue about
> > migrating to rebar3 or mix. I did an experiment to switch
Hello,
There is an https://github.com/apache/couchdb/issues/1428 issue about migrating
to rebar3 or mix. I did an experiment to switch from rebar into mix and wanted
to share the results. The code for experiment is here
https://github.com/apache/couchdb/compare/master...cloudant:switch-to-mix.
Hello,
It is mostly my rumblings at this point. I don't have anything concrete to
propose at the moment.
It seems like our current CI setup is not adequate anymore and currently
broken. In this email I wanted to highlight problems to start discussions about
what we can do to fix it. I also wan
troduction of Elixir based testing framework
into unit testing.
Best regards,
iilyak
On 2019/05/22 18:42:03, Ilya Khlopotov wrote:
> Hi everyone,
>
> With the upgrade of supported Erlang version and introduction of Elixir into
> our integration test suite we have an opportunit
Hi,
Starting formal vote on RFC according to bylaws. RFC
https://github.com/apache/couchdb-documentation/pull/415
Best regards,
iilyak
On 2019/05/22 18:42:03, Ilya Khlopotov wrote:
> Hi everyone,
>
> With the upgrade of supported Erlang version and introduction of Elixir in
Hi Joan,
My answers inline
On 2019/05/22 20:16:18, Joan Touzet wrote:
> Hi Ilya, thanks for starting this thread. Comments inline.
>
> On 2019-05-22 14:42, Ilya Khlopotov wrote:
> > The eunit testing framework is very hard to maintain. In particular, it has
> > t
Hi everyone,
With the upgrade of supported Erlang version and introduction of Elixir into
our integration test suite we have an opportunity to replace currently used
eunit (for new tests only) with Elixir based ExUnit.
The eunit testing framework is very hard to maintain. In particular, it has
of the de-duplication operation to single database and use of
random sampling we would be able to cleanup frequently updated *databases* at a
different rate than less frequently updated ones.
On 2019/03/27 21:55:14, Ilya Khlopotov wrote:
>
>
> > I don’t understand why you want to at
tead
> of using a separate (DbName, Versionstamp) KV each time. What’s the
> advantage? Both structures require periodic cleanup. I also don’t understand
> why you need this DbName -> Versionstamp mapping at all. Is there a reason to
> do some per-database cleanup on the contents of
Hi,
Both proposals are fine but need a consumer process. Which is a tricky
requirement because it will lead to problems in cases when queue grows faster
than we can consume it. This realization got me thinking about finding possible
ways to eliminate the need for a consumer.
I wouldn't spell
There are ongoing discussions about rebasing CouchDB on top of FoundationDB. It
seems like the community is in agreement that it is worth it to try. This would
mean that we would be supporting and extending two quite separate codebases.
How are we going to do it?
Possible options are:
- brand
> The application would override the _all_docs and _changes endpoints, and if
> a user has enabled access=true for that database then you could then return
> the _all_docs and _changes requests from your application. The epi http
> work is pretty fancy I think we could do some cool things around th
) beat shorter ones
> 3) RevHashes with larger binary values beat ones with smaller values
>
> ===
>
> OK, that’s all on this topic from me for now. I think this is a particularly
> exciting area where we start to see the dividends of splitting up data into
> mul
KV, clear it, and write a
> new one with the stemmed content of the ancestry into a key that includes the
> new leaf revision. This also means you don’t explicitly need to add the old
> key into the write conflict range (because you’re clearing it, which will do
> that implicitly
- `{NS} / _meta / external_size` += external_size
## Get list of all known revisions for the document
- range query `{NS} / {docid} / _index / _revs /`
## Changes feed
- we would set a watch for `{NS} / _meta / external_size` key
- when watch is fired we would do a range query starting from "{NS} / _index /
_by_seq / {since_seq}"
- remember last key returned by range query to set a new value for since_seq
best regards,
iilyak
On 2019/02/04 19:25:13, Ilya Khlopotov wrote:
> This is a beginning of a discussion thread about storage of edit conflicts
> and everything which relates to revisions.
>
>
>
bellish later (if warranted).
> > >
> > > I am intrigued by all the ideas that might allow us cheaper inserts and
> > updates than the current code where there are multiple edit branches in the
> > stored document.
> > >
> > > B.
> > >
> > >
e where you’re looking to gain storage efficiencies)
> without doing that full read.
>
> Adam
>
> > On Feb 5, 2019, at 9:18 PM, Ilya Khlopotov wrote:
> >
> > While reading Adam's proposal I came to realize that: we don't have to
> > calculate w
Thank you Joan for proposing this process. It looks great.
> For me, the question that remains is: at what point do we REQUIRE the
> proposed RFC process to be followed? When is a change "substantial?" And
> I think that it may be sufficient at this point to leave it grey-area,
> with the PMC wei
, which
> are something like
>
> 1) deleted=false beats deleted=true
> 2) longer paths (i.e. higher RevPosition) beat shorter ones
> 3) RevHashes with larger binary values beat ones with smaller values
>
> ===
>
> OK, that’s all on this topic from me for now
This is a beginning of a discussion thread about storage of edit conflicts and
everything which relates to revisions.
One of the features of CouchDB, which doesn't map cleanly into FoudationDB is
changes feed. The essence of the feature is:
- Subscriber of the feed wants to receive notifications when database is
updated.
- The notification includes update_seq for the database and list of changes
which happen
bytes + 10*1000+1000*100=112400bytes~=110 Kb
We definitely can reduce requirement for mapping table by adopting rnewson's
idea of a schema.
On 2019/02/04 11:08:16, Ilya Khlopotov wrote:
> Hi Michael,
>
> > For example, hears a crazy thought:
> > Map every distinct occur
least 100KB just by adding up
> all the scalar values?
>
> Adam
>
> > On Feb 4, 2019, at 6:08 AM, Ilya Khlopotov wrote:
> >
> > Hi Michael,
> >
> >> For example, hears a crazy thought:
> >> Map every distinct occurence of a key/value instance
Hi Michael,
> For example, hears a crazy thought:
> Map every distinct occurence of a key/value instance through a crypto hash
> function to get a set of hashes.
>
> These can be be precomputed by Couch without any lookups in FDB. These
> will be spread all over kingdom come in FDB and not lend t
dn't quite understand
the "Couch Range fetch" part of your question)?
best regards,
iilyak
On 2019/01/30 20:11:18, Michael Fair wrote:
> On Wed, Jan 30, 2019 at 9:53 AM Ilya Khlopotov wrote:
>
> > FoundationDB Records layer uses global schema for JSON documents. They
h
is unlikely) if we would have to split CouchDB operation into multiple
FoundationDB transactions. We would need it if we want to allow documents
bigger than 10Mb which we shouldn't IMO.
Best regards,
iilyak
On 2019/01/30 19:58:58, Michael Fair wrote:
> On Wed, Jan 30, 2019 at 11:54 AM Il
trivial fix is to use DOCID/REVISIONID as DOC_KEY.
>
> Mike
>
> On Wed, Jan 30, 2019 at 9:53 AM Ilya Khlopotov wrote:
>
> > FoundationDB Records layer uses global schema for JSON documents. They
> > also have a nice way of creating indexes and schema evolution suppo
either, and with say emit(doc.foo, doc.bar), if
> >>> either emit() parameter was an object, the undefined-sort-order of
> >>> SpiderMonkey would mix things up. While worth bringing up, this is not a
> >>> BC break.
> >>>
> >>> 2. This would have the
efined-sort-order of SpiderMonkey
> >> would mix things up. While worth bringing up, this is not a BC break.
> >>
> >> 2. This would have the fun property of being able to rename a key inside
> >> all docs that have that key.
> >
> > …in one s
Nice API. Few remarks
* GET /_shard_splits
How the `#/states/running` would look like in response to `GET /_shard_splits`
in the case when there are many jobs running. My guess is we would have all
nodes of the cluster in the list. How useful it is to know.
Should we return a number of jobs for
({[{aaa, 12}, {bbb, 1}]}).
<<"{\"aaa\":12,\"bbb\":1}">>
```
Best regards,
iilyak
On 2019/01/30 13:02:57, Ilya Khlopotov wrote:
> As you might already know the FoundationDB has a number of limitations which
> influences the way we might stor
As you might already know the FoundationDB has a number of limitations which
influences the way we might store JSON documents. The limitations are:
| limitation |recommended value|recommended max|absolute max|
|-|--:|---
Hi,
As a continuation of discussions about rebasing of CouchDB on top of
FoundationDB it would be good to start discussions about how different CouchDB
features might be implemented in FoundationDB. It is hard to map all CouchDB
features into FoundationDB in a single pass. Since it is time cons
First I apologize if you receive it twice (slightly different versions as
well). It looks like my email is miss-configured since reply to
dev@couchdb.apache.org from mail client didn't go through.
> This eliminates the "length" of the path string concern and keeps every
> document field a strai
Hello,
Today we discovered a problem with _stats reducer which might be a show stopper
for the release since the feature is documented. More details are in the PR
https://github.com/apache/couchdb/pull/1484. The problematic commit is included
in 2.2.0-RC2.
Best regards,
iilyak
On 2018/07/31
As you've said there are no big contributions to 1.x branches for few years.
I am not sure how many users use 1.x releases.
However, I do believe that spending resources on releases for very old versions
is counterproductive.
It would be better for the project if these resources would be spent e
Awesome. +1
From: Joan Touzet
To: CouchDB Developers , CouchDB Users
Date: 2017/05/17 12:38 PM
Subject:[Lazy Consensus] Move from JIRA to GitHub Issues
Hi everyone.
As most of you know, a few months ago we moved many of our primary
repositories from primary Apa
Fantastic notes!!!
While reading them I notice an Elixir related section. There is no
conclusion on this unfortunately. It also quite hard to infer the sentiment
from the notes. I would love to get a general idea on:
How many people present at the meeting see the value in adopting Elixir and
how
?
Best regards,
ILYA Khlopotov
Hey all,
Thank you for you feedback and great discussion. It looks like I am the
only one who prefer multi-repo model (with tools assistance).
BR,
ILYA
From: Jan Lehnardt
To: dev@couchdb.apache.org
Date: 2016/04/15 01:39 AM
Subject:Re: On dependency management and CI issues as
s
separately, and, as Ilya makes clear, many enhancements require changes to
multiple repositories, and we break this into multiple commits, losing the
ability to look at an enhancement in toto.
>
> If what Ilya is proposing is the solution, I think it's the solution to a
pro
We can issue PRs from the tool itself
- We can merge from the tool itself
- We can implement support for multiple remotes (asf, github, private)
- We can implement support for multiple git transports (for the first
version all repositories in *.deps.json files would use https://)
Sincerely,
ILYA KHLOPOTOV
: Alexander Shorin
To: "dev@couchdb.apache.org"
Date: 2015/10/01 03:36 PM
Subject:Re: [PROPOSAL] Improve testing infrastructure of couchdb
On Fri, Oct 2, 2015 at 1:24 AM, Ilya Khlopotov wrote:
> None of them perfect though. Even though going with elixir
on't waste a time on unimportant
details, I'm +1 for this.
[1]: quite good example here:
http://www.quviq.com/adding-a-github-repository-to-quickcheck-ci/
[2]: https://github.com/h4cc/awesome-elixir#testing
--
,,,^..^,,,
On Thu, Oct 1, 2015 at 11:32 PM, Ilya Khlopotov wrote:
>
&g
Hi,
I would like to submit a proposal to improve the way we test couchdb. Here
is the link to rendered version:
https://rawgit.com/iilyak/e65b4ddf8a46416f84be/raw/4c8dff91d51fcfd6e5a7f65b7e9b0f8c96ee3a61/proposal.html
Bellow is the source of the proposal
--
# Testin
> Is there a way to publish an Erlang module for downstream users
independently of git? If yes, we could move back to a single-git-tree model
for
CouchDB, but we can still release parts as independent modules. I know
there have
been a few attempts at Erlang package managers, but has anything taken
One more option to consider (based on Russell idea expressed personally).
We could follow following process when we create PR.
1. create PR against dependency (or multiple deps)
2. create PR (this is not for merge) for couchdb repo which updates
rebar.config.script to point to PR created in #1
3.
metric definitions from
applications. Henning Diedrich has some unmerged worked which looks to
follow a similar path for HTTP URL handlers. And Ilya Khlopotov has
some work for providing vendor specific hooks.
While each of these have some overlaps in their intended use case,
they also share the
ne the same service? Or use the same service and different
parameters? I think if we go this route then there's going to be a
large amount of unintended complexity without a significant gain in
functionality.
On Fri, May 22, 2015 at 11:37 AM, Ilya Khlopotov wrote:
>
> Hi Paul and Russe
> Background
> --
>
> As we've grown the code base to include more and more applications
> we're getting to the point where we've started adding various points
> of extension in various ways. The best existing example is the
> couch_stats application which loa
Hi everyone,
Paul Davis: +0
Nick Pavlica Logo 1: +0
Nick Pavlica Logo 2: -1
Nick Pavlica Logo 3: +0
Brad Noble: -1
Sean Barclay Logo 1: +1
Sean Barclay Logo 2: +0
Sean Barclay Logo 3: -1
Apache CouchDB (old logo): -1
Constantin Angheloiu: +1
From: Alexander Shorin
To: "dev@couchdb.apach
Hi,
I would welcome any feedback on using proposed plugerl applications to
implement vendor specific hooks
https://issues.apache.org/jira/browse/COUCHDB-2585
https://github.com/apache/couchdb-global-changes/pull/4
https://github.com/iilyak/plugerl
What are the next steps I need to take besides
Hello everyone,
I would love to discuss a possibility of allowing couchdb customisation.
CouchDB has lots of features which are not easy to plug into without
forking the code.
Forks brings extra maintenance overhead which we want to avoid.
It would be very helpful if it would be possible to exte
Hello I have a number of PRs which needs some review and merge. I
appreciate you help with it.
Below is the list
1. Add an ability to tell if view was up to date without querying it.
https://issues.apache.org/jira/browse/COUCHDB-2526
https://github.com/apache/couchdb-fabric/pull/9
97 matches
Mail list logo
