couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] Commented: (COUCHDB-1046) support load of external erlang modules in couchdb.
Date Thu, 27 Jan 2011 18:49:45 GMT


Paul Joseph Davis commented on COUCHDB-1046:

Reading through the docs there are some scary bits here:

On the code path cache:

"To activate it, start the emulator with the command line flag -code_path_cache or call code:rehash().
When the cache is created (or updated), the code server searches for modules in the code path
directories. This may take some time if the the code path is long."

Then there's the section on new vs old code that we're all familiar with from the config with
exported functions and what not that's also important to consider.

I see your point about what type of daemon that's started isn't configurable as of yet, but
I think it'd be better to approach this from the point of view of loading a set of services
that includes the rest of CouchDB rather than having lots of other bits.

I'm also not reading too thoroughly, but restarting all secondary services when any one of
them changes seems like not a good idea.

As to the code paths and $PREFIX/couchdb/erlang/lib thing, I think you're missing a step when
you say "add a plugin via the HTTP interface" because you still have to put the actual code
on the machine. Rather than letting people put code all over the filesystem and then make
us have to deal with dynamically changing code paths, I'd still much prefer having a single
place that people can put code (or perhaps a list of places that is also configurable for

I don't see this as too onerous either. Someone had to do "cp my_app/ /random/path/to/my_app"
so there's no reason they can't do "cp my_app `pkg-config --variable=erl_libs`".

Or in other words, this looks on the outside like its a trivial patch but my instincts are
telling me that this direction is going to turn into a mess of edge conditions and crazy behavior
that we can't predict. The goals I think are good, but I think we should look for a simpler
solution that's more consistent across all of couch.

> support load of external erlang modules in couchdb. 
> ----------------------------------------------------
>                 Key: COUCHDB-1046
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: Database Core
>            Reporter: Benoit Chesneau
>             Fix For: 1.2
>         Attachments: couchdb-plugins-01.patch, couchdb-plugins-02.patch
> If you want to add external modules in CouchDB and load them , you need to set the ERL_FLAGS
environnement variable to the path of a module. 
> The attached patch allows couchdb to load plugins from plugin key in couchdb section.
It add needed path to the code path, so the vm can find modules.
> ex:
>    [couchdb]
>    plugins = plugin1, plugin2
>  Each plugin can have its own section where it set the binaries patch, eventually if
a service need to be added to the supervision you can set the module and function to load
like in daemon section and tel if it's a supervisor or simple service.
> It also allows couchdb to load a plugin service (gen_server or such) to the supervision.
You can choose if the service is a simple daemon or a supervisor.
>  ex:
>    [plugin1]
>    code_path = /path/to/plugin1/ebin
>    daemon = {module, function, [Args]}
>    supervisor = false
> Let me know what you think about it. This patch is really useful here and allows me to
dynamically load modules I want. Also it eases the integration of external module. For ex
I can load my couchapp_ng modules with this lines in local.ini : 
>     [couchdb]
>     plugins = couchapp-ng
>     [couchapp-ng]
>     code_path=/Users/benoitc/work/couchapp_ng/ebin
>     daemon = {couchapp_ng_routes, start_link, []}
>     [httpd_design_handlers]
>     _app = {couchapp_ng_httpd, handle_app_req}
>     [couchapp_ng_handlers]
>     rewrite = {couchapp_ng_handlers, rewrite_handler}
>     proxy = {couchapp_ng_handlers, proxy_handler}
> and can do the same with geocouch etc. Tested here with these modules.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message