sean at basho.com
Wed Nov 23 11:25:59 EST 2011
On Wed, Nov 23, 2011 at 11:17 AM, Andy Skelton <skeltoac at gmail.com> wrote:
> I will be embedding my commit hooks and MR functions in the database
> VM. That's not unreasonable but that is most of my project right
> there. The rest is just a tiny webmachine resource module which
> provides a specialized interface for inputting data into Riak. I might
> also want to embed some riak-distributed janitorial processes.
That's totally reasonable, and the fact that Riak exposes this
functionality (hooks and MR functions) is a risk in some ways. Call it the
"stored procedure" problem.
> Maybe I've misrepresented it by calling this my "application" when
> it's really only an extra part of the database that a client
> application will use. I meant "application" in the Erlang/Rebar sense.
> The real (exterior) application will absolutely use Riak's pb
Aha, now it's more clear.
> Thank you for clarifying in your follow-up email. I understand your
> concerns. Does my use case make more sense now? Can you point me in a
> better direction as to how to make releases with my code embedded in
Yes, and you might be able to make this simpler yet. Instead of building
releases, maintain your code separately (this will also let you evolve it
separately from Riak) and simply add it to the code path and start it using
switches in vm.args. Something like this:
%% Add my application's code to the path
%% Make init start my app, assuming the function myapp:start/0 exists
This will also allow you to roll out new versions without stopping Riak;
just send some commands to the console to reload changed modules.
Hope that helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users