Vendor specific customisation for couchdb

[Ilya Khlopotov <ii...@ca.ibm.com>]

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 extend couchdb without
modifying it's source code.
In order to achieve that I can see two approaches:

- Implement set of hooks in form of {Module, Function, Arguments} (MFA)
configured via app env or config.
- Introduce a notion of vendor specific plugin. Configure plugin module in
config and call hooks like <plugin>:<hook>(Args). Use [vendor] section in
config to specify args to pass to hooks.

I've pushed couple of PRs using approach #1.
https://github.com/apache/couchdb-global-changes/pull/3
https://github.com/apache/couchdb-couch/pull/38

Here is the list of hooks I can think of (incomplete and driven by current
needs):

- ddoc_validator
- dbname_validator - PR
- docid_validator
- mrview_update_notify - notify when there is any change
- seq_formatter (maybe) - "<int>-<hash>" vs [<int>, <hash>] vs fully custom
-
https://github.com/apache/couchdb-global-changes/blob/windsor-merge/src/global_changes_httpd.erl#L89
- allowed_owner - PR

I would love to hear a community opinion on:

- Would you like this customisation to be possible?
- Which approach of the mentioned is better or propose your own?
- What additional hooks you can think of (useful if we go with approach
#2)?
- Should we unify the way hooks handle errors? Return {error, Reason} |
throw | crash?
- How do we pass extra args to hooks? [vendor] section | custom keys
anywhere in config | MFA?

BR,
ILYA

Re: Vendor specific customisation for couchdb

[Alexander Shorin <kx...@gmail.com>]

Hi Ilya,

Personally, I love customizations. This is want allows you to extend,
improve, optimize functionality without much deal with the source
code. However, here I see a few issues:

> - dbname_validator - PR

How this validation could be customized? At first sight, you want to
break out the current regexp constraint and pick database names with
more freedom: with upper case letters, with leading numbers, non-ascii
names etc. All this cool, but potentially leads to compatibility and
portability issues. As I said in PR comments, imagine that you'd like
to use Cyrillic database names. You defines own validation function,
it works, but the way how Linux and Windows stores filenames are
completely different (utf-8 vs utf-16). Will the other code be ready
to handle this case? And if not, what's the profit of such
customization after all?

The other reason you mentioned is to have a control on system
databases list. That's a good one, but I think for this the solution
should be a bit different since what we need is actually maintain a
special list of database names.

Is there any other use cases for this feature?

> - docid_validator

This you can do already today with validate_doc_update function if I
understood correctly the functionality it implies.

> - seq_formatter (maybe) - "<int>-<hash>" vs [<int>, <hash>] vs fully custom

Such customization could easily break all stored replication checkpoints.

> I would love to hear a community opinion on:
>
> - Would you like this customisation to be possible?

Personally, I found two good ones: mrview_update_notify and
allowed_owner. Didn't understand what ddoc_validation should do.
Others are doubtful.

> - Which approach of the mentioned is better or propose your own?

In short term approach #1 is simpler and better. In long term, when we
finally made plugins subsystem, #2 will be preferred imho.

> - What additional hooks you can think of (useful if we go with approach
> #2)?

The ones I miss:

before_doc_read
before_doc_write

Some of these are implemented in rcouch iirc. We need to borrows them
from there.

> - Should we unify the way hooks handle errors? Return {error, Reason} |
> throw | crash?

Yes. Return is better.

> - How do we pass extra args to hooks? [vendor] section | custom keys anywhere in config | MFA?

MFA is quite solid way to define hooks. Depending on A CouchDB may
send default arguments or additional ones. Those additional is
actually proplist/map with all the stuff.
--
,,,^..^,,,


On Wed, Feb 25, 2015 at 10:18 PM, Ilya Khlopotov <ii...@ca.ibm.com> wrote:
>
>
> 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 extend couchdb without
> modifying it's source code.
> In order to achieve that I can see two approaches:
>
> - Implement set of hooks in form of {Module, Function, Arguments} (MFA)
> configured via app env or config.
> - Introduce a notion of vendor specific plugin. Configure plugin module in
> config and call hooks like <plugin>:<hook>(Args). Use [vendor] section in
> config to specify args to pass to hooks.
>
> I've pushed couple of PRs using approach #1.
> https://github.com/apache/couchdb-global-changes/pull/3
> https://github.com/apache/couchdb-couch/pull/38
>
> Here is the list of hooks I can think of (incomplete and driven by current
> needs):
>
> - ddoc_validator
> - dbname_validator - PR
> - docid_validator
> - mrview_update_notify - notify when there is any change
> - seq_formatter (maybe) - "<int>-<hash>" vs [<int>, <hash>] vs fully custom
> -
> https://github.com/apache/couchdb-global-changes/blob/windsor-merge/src/global_changes_httpd.erl#L89
> - allowed_owner - PR
>
> I would love to hear a community opinion on:
>
> - Would you like this customisation to be possible?
> - Which approach of the mentioned is better or propose your own?
> - What additional hooks you can think of (useful if we go with approach
> #2)?
> - Should we unify the way hooks handle errors? Return {error, Reason} |
> throw | crash?
> - How do we pass extra args to hooks? [vendor] section | custom keys
> anywhere in config | MFA?
>
> BR,
> ILYA