[erlang-questions] Unable to create Mnesia table

[Dan Gudmundsson]

On Sat, Oct 11, 2014 at 2:48 AM, T Ty <tty.erlang@REDACTED> wrote:

> The whole lets-create-schema-on-first-start-up-if-it-is-not-there is not
> worth the aggravation IMHO. Personally I would create the schema as a
> post-condition to installation or pre-condition to starting the
> application.
>

That is the intention.

Or otherwise do a test and create everything dynamically, an empty ram
schema is always created if nothing on disc is found.

Use mnesia:change_table_copy_type(schema, node(), disc_copies). to convert
it.

I believe (long time since I did this) you can even use
mnesia:add_table_copy(schema, OtherNode, disc_copies) for the nodes that
will start later.

Create your tables with your distribution configuration.

But do this only ONCE, mnesia will not accept/merge schemas created/modifed
from different nodes.

And when starting the empty 'OtherNode ' use the extra_db_nodes config
param to initiate mnesia connection
to the 'Nodes' with a valid schema.


/Dan


>
> On Fri, Oct 10, 2014 at 8:51 PM, Youngkin, Rich <
> richard.youngkin@REDACTED> wrote:
>
>> Just in case it's helpful to anyone... I've discovered the error of my
>> ways (but I'm still looking towards a solution). This application used to
>> start Mnesia directly after creating the schema (only on the initial
>> startup of course). When creating the release I changed this by adding the
>> mnesia application to the {applications, [...]} tuple in the app.src file.
>> I did this to fix another problem caused by the Mnesia beam files not being
>> included as part of the Erlang distro created by relx.  So in the release
>> version, Mnesia is up and running before the schema is created. So I end up
>> with a started Mnesia application without a schema, which of course is
>> needed to define tables.
>>
>> So now on the my next question, how can I get the schema initialized if
>> Mnesia is started prior to schema creation?  Some guy who gives crappy
>> answers  :) had this post in StackOverflow that gave a partial answer -
>> http://stackoverflow.com/questions/14083367/mnesia-doesnt-restart-with-supervisor.
>> Is this really the preferred way of doing this? Seems like a bit of a hack
>> to me (but I'm still a newbie, what do I know :>).
>>
>> Cheers,
>> Rich
>>
>> On Wed, Oct 8, 2014 at 8:33 AM, Youngkin, Rich <
>> richard.youngkin@REDACTED> wrote:
>>
>>> Hi all,
>>>
>>> I recently converted an existing application to a release using relx.
>>> After that the application isn't able to create any Mnesia tables. I can't
>>> reproduce the problem in the Erlang shell (except by creating the table
>>> before creating the schema). This is confusing because the app code creates
>>> the schema prior to creating the table.
>>>
>>> Here is the error:
>>> 12:20:18.929 [info] Creating a new schema from scratch...
>>> 12:20:18.929 [info] Mnesia started, creating tables...
>>> 12:20:18.929 [info] Attempting to create table with TableDef
>>> {pe_properties,{disc_copies,[{attributes,[key,value]},{record_name,pe_kvpair}]}}
>>> 12:20:18.931 [error] gen_server pe_membership terminated with reason:
>>> bad return value:
>>> {error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
>>> prospero@REDACTED'}}}}
>>>
>>>
>>> Here's the associated application code:
>>>
>>>       error_logger:info_msg("Creating a new schema from scratch...~n"),
>>>
>>>       %% TODO: TEMP WORKAROUND TO DEBUG MNESIA SCHEMA CREATION PROBLEM
>>>
>>>       application:set_env(mnesia, dir, "/var/data/prospero"),
>>>
>>>       mnesia:create_schema([node()]),
>>>
>>>       mnesia:start(),
>>>
>>>       error_logger:info_msg("Mnesia started, creating tables...", []),
>>>
>>>       case create_tables(pe_migrate:get_schema()) of
>>>
>>>
>>> The line application:set_env(...) was added in case the Mnesia directory
>>> wasn't getting created properly due to the move to a relx-built release. I
>>> had a similar entry in vm.args that I may have gotten wrong (-mnesia dir
>>> '"/var/data/prospero"'). Interestingly enough, I don't see any artifacts
>>> associated with the schema creation in the Mnesia dir (e.g., schema.DAT).
>>> I'm wondering if this is a clue as to what the cause is.
>>>
>>> pe_migrate:get_schema()) returns a list of TableDefs. create_tables
>>> iterates through that list creating the tables one at a time. The failure
>>> occurs when attempting to create the first table.
>>>
>>> Thanks, Rich
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141011/da477445/attachment.htm>