[erlang-questions] Mnesia Erlang OTP Application sharing Schema/tables

Ulf Wiger (TN/EAB) ulf.wiger@REDACTED
Tue Jan 29 11:23:11 CET 2008

My preference is to have an explicit 'install' phase,
where the schema and tables are created.

The 'builder'(*) tool offers a simple way to do this,
in that it creates a start script with the start
commands removed for all apps except kernel and
stdlib (it then slaps a .load extension on it).
This way, you can get all the paths and environment
variables set correctly, and then create the schema
and tables safely.

The main point is that the applications should be able
to expect that the tables have been created in advance,
and not engage in complex decision-making logic to
try to figure out why they're not there.

Ulf W

(*) This was a tool that I built long ago to test the
idea of incrementally building boot scripts for each
application, as the system grew. It's in jungerl.

db skrev:
> Hello,
> My scenario is as follows:
> mnesia is distributed and table fragmented(on nd1, nd2).  Now, when 
> application started on ndA 1st and on ndB 2nd.  App on ndA,ndB will 
> access same mnesia schema/tables. I create the schema and table when 
> application is started ndA.  Now, I start same application on ndB and 
> have it not create the schema/tables.  
> App on ndA, ndB are not distributed but two of the same app running on 
> both nodes (ndA, ndB).
> e.g similar to two web app instances, on two different machine, 
> connecting to mysql cluster.   
> if app on ndA or ndB crash and then restared, how do I make the 
> Application so that it does not try to recreate the schema/tables. Is 
> there a way to check if schema/tables are there, so you don't do any 
> schema/table recreation?
> In erlang otp design, you start the 1st app on ndA which creates the 
> schema and table, now you take this same code and run it on ndB.  Now 
> app on ndB will try to create the schema/table.  How to stop this nonsense?
> I don't want to cluster app on ndA and ndB together.  app on each node 
> reads a slightly different config file, but access the same schema/tables.
> thanks,
> russ
> ------------------------------------------------------------------------
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list