On Wed, Nov 23, 2011 at 11:17 AM, Andy Skelton <skelt...@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 > interface. > > 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 > Riak? > > 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 -pz /path/to/myapp/ebin %% Make init start my app, assuming the function myapp:start/0 exists -s myapp 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, Sean
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
