<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Thanks Jesper, that makes sense. So people tend to use a helper (I
guess an escript?) which sets up the database schema & tables
and then they start the app.<br>
<br>
When you say "configuration is embedded in the release", do you mean
the mnesia conf goes in the config/sys.config at the top level of
the release? Does that mean that all the OTP apps included in the
release have to use the same mnesia conf?<br>
<br>
Cheers,<br>
Igor<br>
<br>
<div class="moz-cite-prefix">On 16/04/2018 10:55, Jesper Louis
Andersen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGrdgiXRCbBJqCfFcAOXh+7uaJoSv9-iEtY7=C5kMz73nj4Bwg@mail.gmail.com">
<div dir="ltr">On Sun, Apr 15, 2018 at 1:48 PM Igor Clark <<a
href="mailto:igor.clark@gmail.com" moz-do-not-send="true">igor.clark@gmail.com</a>>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">How do I
set mnesia application environment variables in the release
<br>
project? (Or, maybe, how do I get the OTP application to be
able to <br>
access the release project's application environment
variables?)<br>
<br>
</blockquote>
<div><br>
[..]<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I realise I could be going about this the wrong way -
maybe mnesia <br>
should be configured inside the specific OTP app, even under
a release? <br>
</blockquote>
<div><br>
</div>
<div>One way of going at it, written some time ago when I
wrote the GraphQL tutorial: <a
href="https://shopgun.github.io/graphql-erlang-tutorial/#_plan"
moz-do-not-send="true">https://shopgun.github.io/graphql-erlang-tutorial/#_plan</a><br>
<br>
</div>
<div>[Quote]<br>
<div class="inbox-inbox-paragraph">
<p>A common problem people run into with Mnesia is how to
“get started”.
What people often resort to are solutions where an
initial database is
created if it doesn’t exist. These solutions are often
brittle.</p>
</div>
<div class="inbox-inbox-paragraph">
<p>Here, we pick another solution. A helper can create a
database schema
for us, with all the necessary tables. The real release
<em>assumes</em> the
presence of an initial database and won’t boot without
one. This means
the Erlang release is simpler. There is always some
database from
which it can boot and operate. That database might be
the empty
database since we are just starting out. But in
particular, the
release won’t concern itself with creating an initial
database. Rather
it will assume one is already existing.</p>
</div>
<div class="inbox-inbox-paragraph">
<p>The situation is not much different than using a
traditional
schema-oriented database. Usually, you have to create
the database
first, and then populate the schema with some initial
data. It is just
because of Rails/Django like systems in which databases
are
migrate-established, we’ve started using different
models.</p>
<p>[EndQuote]</p>
<p>Mnesia is part of your release and is started as part
of your release, but its configuration is embedded
within the release. This avoids the whole problem of
creation-if-not-exist, which is probably not a good
solution for a database schema, I think. It is
convenient... until it accidentally the whole database
you had.<br>
</p>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>