Discussion:
[erlang-questions] Unable to create Mnesia table
unknown
2014-10-08 14:33:37 UTC
Permalink
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'}}}}


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141008/af55300b/attachment.html>
unknown
2014-10-10 19:51:55 UTC
Permalink
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
Post by unknown
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.
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
{error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
prospero'}}}}
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141010/e8d3c7fb/attachment.html>
unknown
2014-10-11 00:34:43 UTC
Permalink
What happens if you stop mnesia, create your schema, then restart mnesia?

On Fri, Oct 10, 2014 at 12:51 PM, Youngkin, Rich <
Post by unknown
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 <
Post by unknown
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.
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
{error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
prospero'}}}}
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
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141010/70478400/attachment.html>
unknown
2014-10-11 00:48:28 UTC
Permalink
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.

On Fri, Oct 10, 2014 at 8:51 PM, Youngkin, Rich <
Post by unknown
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 <
Post by unknown
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.
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
{error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
prospero'}}}}
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
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141011/48d96224/attachment.html>
unknown
2014-10-11 07:30:08 UTC
Permalink
Post by unknown
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
Post by unknown
On Fri, Oct 10, 2014 at 8:51 PM, Youngkin, Rich <
Post by unknown
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 <
Post by unknown
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.
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}]}}
{error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
prospero'}}}}
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
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
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.html>
unknown
2014-10-13 14:08:41 UTC
Permalink
Thanks, everyone, for the responses. This is all helpful.

Regarding what happens if I stop mnesia, create the schema, and restart
mnesia - this was how I finally diagnosed what the problem was. IMO this is
a hack that I will replace with one of the other techniques mentioned by
others. I'm still pondering all this given that there are several nodes
sharing the schema.

Thanks again,
Rich
Post by unknown
Post by unknown
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
Post by unknown
On Fri, Oct 10, 2014 at 8:51 PM, Youngkin, Rich <
Post by unknown
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 <
Post by unknown
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.
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}]}}
{error,{unable_to_init_schema,{aborted,{bad_type,pe_properties,disc_copies,'
prospero'}}}}
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
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141013/8282b774/attachment.html>
Continue reading on narkive:
Loading...